With the increasing share of electronics and software components in modern cars, it becomes ever more important, to put them in a logical order with their mechanical counterparts. Modern cars are already the most complex safety-relevant volume products. However, this complexity will continue to grow due to the rising number of assistance and communication systems, leading to autonomous vehicles.
In order to cope with that complexity automotive manufacturers have developed so called electrics/electronics (E/E) architectures. If you are interested in the automotive business, you might have heard about Daimler's EVA2 oder Volkswagen's E³ (end-to-end electronics) architectures.
For most of the others this topic might be hard to grasp, so we will try to make it more accessible with an example most people can better relate to: Building a house. Therefore, we will talk about "the product", when the step applies similar to building a house or developing a car.
Credits by Anja Möstl, accilium
Whether it is a house you are building or a car you are developing, you will have to folllow certain steps. To not forget any, it is good to have a plan, listing these steps. In the development of technology, often a concept called the V-Model is used.
To make it short, the V-model contains the requirements for the product to be developed, their composition through an architecture and creation of technical solutions on the left side and the integration and test of these solutions on the right side. The further you go down the V, the more detailed and granular are the descriptions of the mentioned steps.
Thus, the V-Model can help to cope with the complexity of your product by breaking it down into manageable sized bites. These bit es can be allocated to the various specialized development teams or contractors.
This means, that all of the following architectural steps should be considered for each level of the V-Model, e.g. on the system-level, where you look at the product as a whole, as well as on the sub-system level, which focuses on a small fracture of the whole system, or even on the component level, representing the smallest singular part of the product.
As first step, you will have to make up your mind about the requirements for your product. This is defined by various stakeholders: The customers and what they want, but also certain laws and standards or technical limits when it comes to the construction.
All those we therefore collectively call the stakeholder requirements. They are the outside view on how the final product should look like.
In the next step you need to translate this external view in requirements, which your company understands. Often your customers describe a situation or a rather abstract use case in their requirements, which then need to be converted into requirements, phrased as certain properties or functions of the product which your experts understand and can later implement in the product. Those requirements are then called system requirements, they can be seen as the internal view on the requirements by your company.
It is extremely important to ensure a sophisticated requirements engineering, doing these steps. If you aim too low, your customers will be disappointed; if you aim too high your product will be over-engineered and too expensive.
Now that the product has been described, the hard work begins. All system requirements must be represented in a comprehensive architecture.
This comes with a couple decisions the chief architect has to solve with the stakeholders and his expert team, who supplies him with proposals for solutions. As a result a coarse structure of the final product will be determined. You can imagine this coarse structure as the decision whether to build small wood house or a skyscraper, or in the automotive context whether to build a car with an internal combustion engine or a battery electric vehicle.
To develop a great product, we then have to do the real architecture work, which is breaking it down in manageable-sized bits. To do this for complex products such as cars, we have to distinguish between the following architectures:
The functional architecture describes all functions, which need to be fulfilled by the product and how they are broken down. The main functions are derived from the system requirements and described on a rather high-level.
They are then broken down into smaller, less complex sub-functions. The functional architecture describes the hierarchy of functions and how various sub-functions are interconnected, it does however not specify how the functions are technologically realized.
This is done in the logical architecture. In this step, the functional architecture is described in process chains of abstract technological elements, such as sensors, controllers or actuators. It further defines the interfaces of the different elements. As mentioned, the technological elements are only abstractly described and no parameters are defined.
In the last step, the technical or physical architecture, it is specifically described, which technical solutions are used to realize the functions and properties, as well as the interfaces they have with each other. Also all parameters are defined and CAD-models or wiring diagrams are created. The physical architecture can be seen as the blueprint for the production of the final product.
As mentioned above, those architecture steps need to be repeated for each stage in the V-Model. This sounds like a lot of work, but if you follow them, it will help you tremendously for the development of complex products such as cars.
Architecture can therefore be seen as one of the most important disciplines of systems engineering and the need for E/E architects will continue to rise steadily.
Article published by Rafael Schmid
