In many industries, embedded software plays an increasingly important role in defining the characteristics of the products. Often, a product line approach is used, and the system architecture is developed through evolution rather than being redone from scratch for each product. In this paper, we present a model of such an evolutionary process based on architecture transformations. The model attempts to give an accurate description of how real architects actually work. Key elements of the approach are how the transformations interact with consistency constraints and with feasibility in terms of resource limitations. The work is based on findings from previous case studies in the automotive industry. The model can be used to enhance our understanding of the architecting process, and to find ways to improve it.
The increasing complexity of embedded systems leads to soaring development costs,
and many companies strive to curb this trend by reusing software and hardware
between products through a product line approach. This makes architecture very
important, and we have previously done in-depth studies of the architecting practices
at a some companies (see e.g. [
In the evolutionary process, architecting is triggered by a product change request. The architects get input in terms of requirements primarily from the function developers. The architects then try to design a high-level technical solution, focusing on the distribution of functionality onto different systems, and on the interfaces between systems. When designing the high-level solution and evaluating alternatives, they take into account not only the requirements, but also architectural quality attributes, which are properties of the architecture itself which they strive to maintain. Throughout the work, the architects create descriptions of the architecture. The descriptions are used to define pre-requisites for the system developers.
The architect primarily focuses on resolving issues that go across several subsystems, and this entails dealing with the following concerns: • Feasibility, i.e. possibility to implement the functionality by the available computational resources. • • •
Consistency, i.e. that all interfaces between parts are well defined.
Optimality, in terms of important quality attributes (including cost).
Modifiability, to enable future evolution.
The model presented here attempts to describe what information the architects deal with in their work. That information might appear in many forms: formal models, sketches, texts, or just as mental models inside the architect's head. Our model tries to capture the essence of that information, and disregard its representation.
For modeling the architecture descriptions for embedded systems, it suffices with a metamodel (M2 level) that is essentially an annotated graph, containing elements of different kinds; relations between pairs of elements or between pairs of relations; and attributes describing properties of elements and of relations.
For distributed, embedded systems, a model (M1 level) for describing the
architecture can be grouped into several levels of abstraction. In this paper, we will
use four different views, whose elements and relations are shown in Table 1. (The
description is similar to that provided in [
The metamodel allows attributes on elements and relations describing their properties. For architects, the primary properties have to do with desired qualities and limited resources present. The desired qualities are those properties that the architect tries to optimize when selecting among alternative feasible solutions. One of the most important ones is cost, which can be further divided into product cost and development cost. The product cost is essentially the cost of hardware, so we add a product cost attribute to each element of the hardware view. Important resources are present in ECUs (processing capacity, memory size, I/O pins), communication channels (bandwidth), and spaces and routing channels (volume).
Architects do usually not make complete models of the entire architecture, but rather only describe those parts which are relevant to resolve a certain change request. Therefore, we should not assume that we are dealing with complete information. However, among those elements related to the change request, consistency must be reached so that for instance all necessary relations are present. As an example, if the change is to add a new function, which is realized by a certain set of modules, all those modules must be allocated to ECUs, and none can be left dangling.
We believe that the essence of the architect's work can be captured as a sequence of transformations of the architectural description (on the instance, or M0, level), together with analyses to see that the solution is feasible, cost efficient, and future proof. Just as the architecture descriptions can take many forms, including mental models, the transformations can in reality be explicit or very implicit.
There are two basic transformations on the metamodel level: add entity and remove entity. Since the entities are either elements or relations, the possible transformations become add element, remove element, add relation, and remove relation. At the model level, these abstract transformations can be made concrete, resulting in, e.g., add module, remove ECU.
Sometimes architects also use composite transformations. A good example is change relation, which basically consists of add relation1 followed by remove relation2. A concrete example is when a module that used to be allocated to one ECU is moved to another ECU by a change allocation transformation. Other composites are change element (e.g. change ECU to, e.g., an upgraded processor); split element (e.g., split module when a software module is divided to allow distribution); and the reciprocal merge element. Through the composite relations, we end up with a formal language which is very close to the natural language used by architects during their daily work.
As described in Section 2, the architect's work is triggered by a change request to an existing architecture, which is consistent and feasible. This change request can be described as an initial set of transformations. A typical change request is to integrate a new function, i.e., the transformation add function. At this point, the architecture description has become largely inconsistent.
The first step of the architect is usually to try to get more details about the functionality in the requirements analysis phase. This involves identifying external entities involved (using the transformations add external entity, add functional dependency). Also, it is important in this phase to identify placement limitations. After the requirements analysis is completed, there is usually a complete and consistent description of the functional view.
Next, the architect starts to generate possible solutions. This is done by filling in the details at the logical level through transformations such as add module, add dataflow, but also change module since a consequence of an added functional dependency may be that an existing module needs to be updated. Also, the hardware view is detailed, possibly by add ECU, add sensor, add actuator or add network transformations. The relations between the logical and hardware views also need to be figured out, by add allocation transformations. In this step, it is common that the logical view needs to be revisited to perform split module transformations in order to find a good allocation. Finally, the hardware and positioning views must be connected by add positioning and add routing transformations. According to our observations, there is usually not a clear step-by-step process through the views, but the architects appear to work with all views in parallel or iterate between them. Figure 1 illustrates the search process performed by architects when dealing with a change request.
Change request 2
4
Initial architecture 1 5 3 6
Final architecture 7
Feasible and consistent Feasible and inconsistent Infeasible and consistent Infeasible and inconsistent Transformation(s)
If consistency is what drives the architecting forward, analysis of feasibility and quality is what guides it. The most important analyses correspond to the concerns of the architect described in Section 2 above. Usually, the analyses are qualitative rather than quantitative, and often relative rather than absolute. Difficult trade-offs between the concerns are often needed.
For each resource, a set of users can be derived to see that the solution is feasible, i.e. that the resources are not exhausted. Whenever a relation is added to the model, which entails that one element will use resources of another, the feasibility should be checked. An example is when a module is allocated to an ECU. Then the architect must evaluate if it will fit in terms of ECU memory and CPU footprint.
The product cost is simply the sum of the cost of all components, which can be calculated by adding the cost attributes of all entities in the hardware view.
Development cost is more complex to assess. In [
The architects also try to keep in mind that the architecture should be modifiable.
However, as pointed out in [
In this paper, we have outlined a Transformation-based Evolutionary Architecting Model (TEAM), which attempts to describe essential knowledge about how real architects go about developing embedded system product lines. The basis is data collected from observing real architecting work, and we have attempted to construct a model with a high fidelity in the sense that the language the architects use to describe their own process should be possible to map to the model.
Although the model presented in the paper is largely based on experiences from the automotive domain, the fundamental ideas are captured in the metamodel which is much more general and allows many different views and elements to be included.