The systematic development of a system and software architecture

This article covers the procedure for designing and documenting a system architecture using a systematic and structured architecture process.

The article is structured as follows:

1. Definitions – Defines the terms used in this article.
2. Development process – A brief description of the system development process in which the architecture process is embedded.
3. Architecture process – A description of the procedure for designing a system architecture.
4. Architecture documentation – Shows how the architecture process and the architecture created are to be documented.
5. Integration – Describes what is to be considered when integrating components defined by the architecture into a total system.
6. Summary – A summary of the most important contents of this article.

1. Definitions

The system architecture is defined as follows according to Wikipedia:

System architecture, derived from the definition of architecture in general (= building art …), refers to the discipline (field of activity, task, management) that focuses on systems and the components that interact within them.

The components of a system architecture include both hardware and software. In the case of software, it is also referred to as software architecture. However, in the context of an embedded system, it is very important that the software architecture is understood as part of the system architecture.

In this article, the following terms shown in Figure 1 are used in accordance with ISO 42010:

System / Embedded System
The system for which an architecture is to be developed. An embedded system is an electronic computer or computer that performs a defined function and is integrated into a physical environment, optionally surrounded by other surrounding systems, and optionally has a user interface.

Environment
The environment in which the system is used.

Architecture
The actual architecture of the system. This results from the implemented components and their interaction.

Stakeholder
A person or group with an interest in the system.

Requirement
Describes a single interest of a stakeholder in the system. There are functional requirements and non-functional (quality) requirements.

Architecture Description
The description of the architecture documents the result of the architecture process. This should represent the actual architecture as well as possible.

 

2. Development process

A systematic and structured approach is recommended for the development of embedded systems. The V-model (See https://de.wikipedia.org/wiki/V-Modell) approach has proven itself in practice.

The procedure can be roughly divided into the phases shown in Figure 2:

• Definition
• Analysis and specification
• Development
• Integration and verification
• Validation
• Maintenance

Architecture plays an important role in all phases of the development process.

 

Definition
The system definition represents an important input for the architecture.

Analysis and specification
In this phase, all requirements for the system to be developed should be captured. These serve as inputs into the architecture to be created. Then the architecture process is started, and the system is decomposed into subsystems. The created subsystems are specified. The procedure is described further down in the chapter architecture process.

Development
If the requirements and the architecture are certain, the system can be realized. Here the individual components are developed first separately and integrated afterwards to the Subsystem and finally to the complete system. If changes are made to the architecture during implementation, the architecture process must be run through again to avoid inconsistencies in the architecture.

Integration and verification
It must be ensured that the conversion of the components corresponds to the architecture defined before. Therefore, the individual components are verified on the basis of the requirements. With the integration process, the integrated components, subsystems, and the finished integrated system should be verified.

Validation
Finally, the system must be validated against the definition to ensure that it can meet it.

Maintenance
Even after the system has been developed and is already in use, there are often changes such as bug fixes or additions of new functions. Often the V-Model is run through again for this purpose. It is also important that the architecture process is run through for such changes. Otherwise, there is a risk that the architecture will degenerate during the lifetime of the system, which can lead to errors in the system and increased costs in development.

 

3. Architecture process

How do you get from system requirements to a good architecture? The best way is to proceed in a structured and systematic manner and document each step. This procedure should be defined in an architecture process. Such a process based on Attribute-Driven Design (ADD) (See https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8147) is described below.

 

Is there a systematic approach to tackle a problem that seems (too) difficult?

Of course! Even the phrase ‘breaking something down’ is a clear indication of a very successful concept. The division of a problem into smaller sub-problems and the subsequent merging of the partial solutions into an overall solution. This concept has been used for a very long time, especially in the creation of algorithms. Today the paradigm is known as ‘divide and conquer’ (See https://en.wikipedia.org/wiki/Divide-and-conquer_algorithm) and is probably familiar to many software developers.

But the paradigm is also often used in the system design process, where the architectural elements are broken down (decomposition) until manageable, clearly defined components are determined. This is where the transition to implementation takes place.

Therefore, one of the most important tasks of architecture is the division of a system into clearly defined components. These are broken down again into subcomponents. Each component has a clearly defined task in the system and communicates with other components over exactly defined interfaces. Thus, architecture levels develop. The interfaces of a level are propagated to the next lower level, i.e., they must be realized by one of the components on this level.

 

Important:

An architecture process is an iterative process in which the architecture is created starting from the inputs and is refined further and further. The architecture is complete when all inputs are considered.

The steps shown in Figure 3 are performed for each iteration:

Check inputs

An architecture is influenced by various factors. It is important that these are identified and understood to develop a goal-oriented architecture. Inputs can also change during the development and product lifecycle, so even in later iterations they should always be checked to ensure they are still correct and complete.

Architecture inputs come from these sources:

• Functional requirements
• Quality requirements
• Constraints
• Environment
• Risk Management

 

To create the architecture, it is not necessary that all inputs have already been fully specified. The most important inputs are those that can influence the architecture.

If the required inputs aren’t available yet, one should wait with the refinement of the architecture or at least the affected components until these are available. Otherwise, there is a risk that important factors will not be considered, and the architecture will have to be adapted again.

 

Functional requirements

The architecture must be able to fulfill all functional requirements placed on the system. Therefore, all architecture-relevant requirements should be known.

 

Quality requirements

In addition to functional requirements (see above), there are also non-functional requirements. These are summarized in this article under the term quality requirements.

Examples of quality requirements:

• Temperature range in which the system must be able to be used
• Response time of the user interface
• Availability of the system (service level agreement)

 

Restrictions

In addition to the requirements (see above), each architecture is also influenced by further constraints. These can be of a technical or organizational nature. These constraints should be clearly documented and can be used as justification for architectural decisions.

 

Examples of technical constraints are:

• Limited hardware resources such as RAM or flash memory.
• Programming language(s) to be used.
• Components or subsystems to be used (reuse, inventories, …).

 

Examples of organizational constraints are:

• Using a specific architecture framework that specifies, for example, the viewpoints to be documented and diagrams to be used (UML, etc.).
• Applicable processes for development and design.
• Applicable standards and laws.

 

Environment

The system does not exist in isolation but is embedded in a system context. This is defined by its environment.

The system context includes:

• Environmental influences (pressure, temperature, …)
• Surrounding systems
• Users
• External interfaces

 

Define the goal of the Iteration

It is important to be purposeful in each iteration. This allows a more efficient approach. It also allows critical components and subsystems to be addressed first, or those with missing inputs to be further detailed later.

In the standard case of an architecture production, the system is iteratively dismantled starting from the entire system (Decomposition). Therefore, the goal of these iterations is the decomposition of the accordingly selected (sub)system or a component. An iteration could also be a refinement of the architecture for a topic, i.e., implementation of security requirements.

 

Identify architecture drivers

Once the goal of the iteration has been defined, it is important to select the inputs relevant to this iteration from the list of all inputs. These are called architecture drivers since they influence the architecture to be created.

 

Develop and select a design concept

Often there is not only one variant of how to solve a problem, but several. Therefore, it is important that the different variants are identified and evaluated. The architecture description should also describe variants that have not been selected and justify the selected variant. This helps to understand architectural decisions later in the life cycle of the system.

 

Create/add architectural elements

The decomposition or refinement of the architecture is now performed according to the previously evaluated concept. For this purpose, the necessary new architecture elements (subcomponents) are introduced, and the responsibilities assigned, or the existing architecture elements are supplemented accordingly.

When naming newly introduced subcomponents, it is important to ensure that they provide a clear indication of the component’s responsibilities.

 

Example

The following component is to be dismantled (1^st architecture level):

The component has three external interfaces

• Dc12V: Supply
• SystemBus: Serial interface to an Um-System
• ErrorLED: LED for error indication during development

 

At the 2^nd architecture level, the component is split into two subcomponents:

The external interfaces of level 1 are assigned to the subcomponents. A new interface is defined between the two subcomponents. This is an internal interface from the point of view of the level 1 component, but it is also an external interface for the level 2 components.

In DATAFLOW Designer, components can be disassembled with a single click. All external interfaces of the component are automatically propagated to the next architectural level.

 

Define interfaces

Once an iteration has been performed, it is important that all newly introduced interfaces between the components are defined.

To avoid confusion, it is very important that the naming of the interfaces is unambiguous and is maintained across all architecture levels and architecture views (both hardware and software).

In DATAFLOW Designer, the names of defined interfaces are propagated from top to bottom. This prevents inconsistencies in naming within the DATAFLOW software.

 

Verify and refine

The created architecture should now be verified based on the inputs. This ensures that the selected variant can also meet the requirements, constraints, etc. This can be done for example by a review with another architect. In doing so, the list of inputs is reviewed, and it is shown how these have been addressed in the present design. Then the next iteration can be started to further refine the architecture.

 

Architecture description

The architecture defined during the architecture process should be documented in such a way that all information is available for implementation in the ‘Development’ phase of the development process and the selected design is comprehensible.

The exact content and structure of an architectural description will be discussed in more detail in another article. It is important that the individual iterations of the architecture process are also documented as part of this description, and not just the finished architecture. This allows us to understand architectural decisions in all phases of the life cycle of the system.

 

Breakdown of the architectural description based on decomposition

Decomposition in the design process serves to refine the definition of the system until implementation can begin. Not only the components for the solution of the sub-problems are defined, but also the interaction of these to obtain the desired overall solution. This results in a hierarchical structure for the system architecture, which is usually described in one or more documents by means of illustrations and text.

Figure 4 shows an example of the structure of an architecture description. The arrows represent on the one hand the hierarchical dependency and on the other hand the information flow (designations etc.) during the design process.

Integration

As already explained above, the decomposition of a system into components has many advantages. However, these components must ultimately interact as a complete system in the integration phase of the development process. If each component is developed individually and possibly by different teams, this can get out of focus during the development.

This can lead to various problems:

• Integration problems by incompatible interfaces
• Errors due to side effects of components
• Conflicts by use of the same interface in different components

 

How these problems can be avoided is described below.

 

Incompatible interfaces

The interfaces between components must be clearly defined. Furthermore, it must be ensured during the verification of the components that the specification of the interface has been adhered to. Furthermore, completeness must also be ensured when specifying the interface. Often temporal aspects are forgotten or specified inaccurately, which can lead to problems during integration.

In DATAFLOW Designer, interfaces are propagated automatically and can be linked to the interface specification. This ensures that no interface is forgotten, and the relevant documentation is available for all components.

 

Side effects

If a component influences the system through an undocumented interface, this is also referred to as a side effect. This can lead to various errors, some of which can only be discovered after the components have been integrated. To avoid these, care must be taken to ensure completeness when defining the interfaces of a component. In this way, the side effects become visible in the architecture description and can be considered. It may also be possible to avoid the side effects by splitting components differently without having to introduce a new interface.

The graphical representation in DATAFLOW Designer shows the interfaces and their interrelationships. In this way, all interfaces of a component can be clearly recorded.

 

Conflicts

If an interface is used by more than one component, conflicts may occur. For example, if two components use the same LED, the second component would override the state (on/off) of the first component again.

Therefore, each interface should be exclusively assigned to one component on an architecture level.

In DATAFLOW Designer this is ensured automatically since an interface can only be used in exactly one component at a time.

Developing a good system architecture requires a well-structured and systematic approach. The architecture must be continuously updated and reviewed to take account of changes in the development and product life cycle.

For the architecture, all inputs such as stakeholders, requirements, constraints, and the system environment are first collected. Then the architecture is refined in an iterative process.

An important aspect of a system architecture is thereby the decomposition of the system into components and subcomponents (parts and rules). It is important that all interfaces on the next architectural level are propagated and assigned in each case to a component.

For this, a component is selected and this is decomposed. The considerations and decisions made in the process must be documented.

The architecture created in this way must be documented in an architecture description.

Likewise, not to be forgotten is the integration strategy, with which the individual components are again integrated into a total system. This should already be considered in the architecture process.

Learn more about IMT DATAFLOW – platforms, tools, and know-how for the development of embedded systems by clicking here.