Design for test and design for safety

This gain in convenience, however, calls for more stringent security and safety requirements which have to be managed by those developing such systems. This is especially true for autonomous driving where efficient safety concepts are top priority. Thomas Batt and Ingo Pohle, MicroConsult GmbH discusses.

Know-how and skills a software architect should have

Image 1: Software architecture – fit for your project

Increasing product complexity and more powerful hardware have resulted in a growing scope and complexity of software in embedded systems. Software implements a major part of functionality in most systems. Embedded software development divisions are growing continuously. This becomes particularly obvious in the automotive sector and in the current labour market. Mercedes Benz, for example, plan to generate most of its revenue through software-based systems from 2030 on. Software development is no longer a one-man-show but done in large teams distributed over multiple locations worldwide.

Over the past few years, embedded software has gained in significance dramatically in most companies in the embedded industry – even in mechatronics. But this is only the beginning.

A stronger focus on agile software development methods

Agile software projects use evolutionary software architecture development, amongst others, based on test-driven software development techniques. These are the two main approaches:

• Functional architecture: The software system is represented by functions or features and their dependencies
• Component architecture: Develops a rough draft as well as several detailed drafts containing a fine-tuned structure of the software

Software architecture is the key to project success

Software architects who shall meet the requirements of their responsible jobs need extensive know-how covering these key aspects:

At an abstract level, the software architecture is a bridge between the requirements and the implementation of software. In software, the architecture describes the rough structure (also modules and classes in exceptional cases) consisting of e.g., software components, software layers, software subsystems, interfaces, and their dependencies. For these architecture elements, it is also possible to describe interactive and individual behaviour. The runtime architecture is another key element of the software architecture.

Everyone with the required know-how can take on the role of the software architect in a company. However, for a really professional approach, I think that the individual role should be preferred. One or more software architects are involved in a project depending on its size.

The software architect coordinates everything with multiple roles in the project and therefore requires technical and non-technical knowledge – the more experience, the better. The role of software architect should probably not be assigned to an inexperienced university graduate – it calls for an extroverted, innovative, decisive, and experienced personality.

Image 2: Software architect

Design process – creating a software architecture

The design process describes the development process of the software (architecture). Every company has to identify and implement the process that is most suitable for them. The software architect plays a key role in defining this process.

Based on a V-model type representation, the design process can be applied to the development of a complete embedded system, i.e., not only to the development of software.

Requirements (what) and the related architectures (how)

In analytic processes, analysts (in most cases also the architects) on the individual levels identify and document the respective requirements (‘what’). These requirements are the basis for creating the architectures (‘how’). Based on a subsystem architecture, the software architect develops the software architecture for a subsystem in coordination with other development domains at the same level (e.g., hardware development).

In line with the requirements, the test team develops test cases to prove correct implementation later in the development process. This is also done at different levels. ‘Design for test’ and ‘Design for Safety’ are basic topics in the context of software architectures.

Image 3: Design process for embedded systems

Design basis and influencing factors

The software requirements (functional and non-functional) are derived from the X analysis (here: software analysis) shown in Image 3.

By analysing the influencing factors, the software architect determines:

• the relevance of the requirements for the software architecture
• the changeability of the requirements in future
• the derivation of consequences for the software architecture

Non-functional software requirements include software quality attributes of the software, such as:

• portability
• maintainability
• reliability
• safety/security
• resource requirements
• performance
• real-time compatibility

Table 1: SAFETY – from a perspective of relevant software quality attributes

Table 2: RELIABILITY – from a perspective of relevant software quality attributes

Some quality attributes are consistent, others can also have opposing effects.

With this in mind, we can ask the following question: Which requirements have a stronger impact on the architecture – functional or non-functional?

The correct answer is non-functional requirements.

Consequently, the software requirements and the resulting influencing factors are the most essential design basis for the software architecture, besides the subsystem architecture.

Communication and documentation

With a comprehensible software architecture documentation, the software architect provides the foundation for a project for all stakeholders and thus full traceability for everyone involved in the project, ensuring the continuity of the company.

Documentation is also the communication basis that shall be continuously coordinated with the stakeholders.

The most important stakeholder here is the software developer who refines the software architecture in detail and finally implements it in the target programming language. In addition to the software developer, other roles like the test team have legitimate interest in the software architecture. You cannot verify whether implementation is correct unless you know what is required.

Image 4: Exemplary layered software architecture

UML (Unified Modelling Language) is the notation for documenting various views and aspects of the software architecture and refining them in design – up to automatic code generation. The package diagram shown in image 4 models the different software layers.

Software design principles enhance software quality

Our whole life is determined by rules – even if some people think they don’t have to stick to them. All of us have been confronted with the COVID-19 pandemic and the related regulations and rules. You certainly played Lego as a child, or you do so with your own kids today – there are also rules on how to fit the bricks properly.

The software architect with his continuously growing knowledge draws the style guide for software development, describing the rules along which the software architecture shall be developed. Those rules cannot be applied to any architecture as they depend on specific requirements. Applying rules to a software architecture enhances the software quality in any case.

High cohesion is an architecture design principle. It aims at reducing redundancy by processing logically related tasks in one architecture element instead of distributing similar tasks across multiple architecture elements. Specific design principles have been published that can be applied to embedded software architectures. Software architects can implement the design principles in a real system by means of software architecture patterns.

Architecture development and architectural patterns have to meet safety requirements

Based on their technical knowledge, software architects develop the software architecture. Doing so, they use their pattern catalogue. In general, patterns are known, proven, rated and adjustable solutions to recurring issues (challenges). For example, aspects like functional safety and reliability have to be considered and taken care of in safety-relevant systems.

In systems that provide us with fully automated support (think of automated driving), safety and reliability are the key to the success of a product.

Table 3: SAFETY aspects

Table 4: SECURITY aspects

Using patterns can be a challenge in software architecture development.

For example, only square bricks are available, but one requirement might be a rounded outline. This could be solved by means of a graduated assembly of the bricks – according to the Lego principle – in one or several rows. As we are not the first generation to develop software, patterns have already been created for almost all areas of software development and even for the development of software architectures. 

One example is the layered pattern (strict or not strict). Image 4 shows a non-strict software layer architecture. Non-strict means that it involves cross-layer accesses which is particularly helpful for embedded software to achieve the required performance. In this example, also contains vertical layers in addition to the classic horizontal layers.

Quality assurance and quality assessment

The software architect is responsible for the software quality and quality assurance. The quality attributes have to be defined before developing an architecture. The software architect knows the impact of these attributes on his software architecture, and the software test team knows how to prove them. By the way, attributes cannot be ‘tested into’ a product at the end of the development process.

In the context of quality, there is a differentiation between:

• internal quality (e.g., software architecture)
• external quality (what the customer sees)

Process quality has a major impact on product quality. To get back to the Lego analogy once more – all bricks have to be assembled such that they support the structure, otherwise, it will collapse as soon as additional expansions are made. This is also true for software architectures – they have to fulfil all quality requirements and provide all functions that were defined before.

Software architectures were expected to remain functional for 20 years or longer in the past. Today, they are under continuous expansion and improvement – due to emerging requirements, regulations, and laws. For this reason, the development process shall accommodate this aspect as it is key to the further development of a product.

Image 5: Quality assurance and assessment

The easiest way to assure quality

Reviews with other architects and stakeholders are the easiest way to assure the quality of the software architecture. They serve to assess whether the architecture complies with the required quality attributes. The software architecture documentation generated by means of an UML model is a suitable basis for a review.

In a scenario-based review, participants go through pre-defined cases with the architecture. For example, if an architecture is required to be portable in terms of hardware, this process includes an exchange of hardware so as to prove that the software architecture can meet this requirement. The SEI (software Engineering Institute der Carnegie Mellon University) has developed an extensive method to this end, called ATAM (Architecture Tradeoff Analysis Method).

Further quality assurance methods are, for example, prototypes or mathematical models, performing simulations or determining metrics.

Tools makes it easier to develop the software architecture

The software architect is responsible or at least co-responsible for the tool environment for software development.

Image 6: Use of tools

He knows the tool market, identifies the demand, develops tool requirements, evaluates, and finally selects the tools. In a company that does not have a tool group, he is also in charge of tool integration. The tools shall make work easier for everyone involved in software development. Especially for the software architect, it can’t hurt to be a bit egoistic here, as he might benefit the most.

Tools make the work of the software architect easier:

• requirements management
• version and configuration management
• modelling
• generation of documentation and program code
• build systems
• static analysis
• dynamic analysis

Implementation of the software architecture

The software architect passes the entire architecture, or parts thereof, on to one or several software developers for further refinement (design and implementation). The coding style guide, created by the software architect in collaboration with the software developers, shows how the software architecture is implemented in the target programming languages. Typical target languages for programming embedded systems are C and C++.

In C++, the software architecture can be represented efficiently in the program code by means of namespaces.

Image 7: Coding style guide

The software architect and software developer have to make sure that the defined software architecture is preserved over its entire lifecycle and not programmed ‘to death’ – also referred to as software erosion.

If the software developer identifies a need to change the architecture, all related decisions and the changes to the architecture are coordinated by the software architect in charge.

The higher the requirements on safety, security, and modularity of a product, the more critical and significant the role of the software architect in the entire development process.