Embedded clean code in the A-SIL series development environment

Practical experience in high-quality software development

Author: Thomas Winz, softwareinmotion GmbH

Contribution – Embedded Software Engineering Congress 2017

Jurassic Park [R1]: "They were worried about losing animals, and the program is designed to immediately sound the alarm if there are fewer than expected. But that's not the problem. The far bigger problem is that you have more than expected." Who hasn't experienced ill-considered, system-critical requirements?

The underlying reference project is softwareinmotion's first independent in-house product development of an ASIL-certified control unit. Sales partners and external ISO assessors were identified as equal stakeholders.

Product development followed Scrum. The extensive agile tailoring measures of ISO 26262 were summarized under the term "additive architecture style," including "requirements as tests," risk architecture, TDD, code hygiene, continuous testing, deployment chain, and agile hardware. The necessary quality of the source code was ensured through embedded clean code. Additionally, infrastructure had to be created and ISO safety arguments documented.

Since all activities follow the product backlog prioritization, our agile approach enables a successful project. We were able to transform our extremely uncertain project environment into a manageable and predictable space.

Extreme uncertainties

Using the "lean Startup/Startup Way" method, Eric Ries observed that product development in a R&D department suffers from "extreme uncertainty." [R2] The process of continuous innovation (Figure 1, see PDFThis states that effort is only invested if it reduces the overall "uncertainty" in the project. The classic V-model is extended. This method for evaluating success represents a fundamental difference from "agile but" or classic project evaluation methods.

Mental models [R3] of highly qualified specialists compensated for project uncertainties, since technical requirements dominate in embedded products. However, modern consumer user experiences are increasing the importance of business requirements in industrial environments (see Table 1, PDFThis increases the entrepreneurial risk for technically rigid companies compared to agile competitors.

Prototypes are functional aid models used before development begins to clarify uncertainties (see Figure 1, PDFDuring validation, these placeholders simulate the product's behavior. In a high-security environment, the lifecycle of an ASIL product begins as an abstract system model of safety analysis. The SPRINT process describes how project-critical uncertainties are addressed within five days. [R5]

In the reference project, prototypes were used extensively, including Excel, VBA scripts, Arduino sketches, development kits, Qt, and Paint. Formulating a sound question was the biggest challenge, followed by clear documentation. Ambiguities in the question led to elaborate prototypes that, consequently, did not provide a concrete answer within the available timeframe.

Agile hardware development

Until a few years ago, hardware development tools hindered an agile approach to hardware development. Generally, software uncertainties and requirements in embedded systems cannot be resolved without considering the hardware. The "Big Bang" methodology, which integrates various software and hardware elements into a single component or complete system late in the project, is considered outdated.

Dr. Tobias Kästner and Mario Bunk [R6] demonstrated with their „agile hardware development concept“ that any hardware feature is predictable and implementable within a few weeks. To achieve this, each feature is outsourced to individual feature boards and integrated into a project-specific development rig. Adding, replacing, and refactoring individual hardware features are therefore solely dependent on product backlog prioritization.

Image 2 (see PDFFigure 1 shows the in-house developed universal test bench. This test bench utilizes the developer software toolchain to emulate necessary vehicle characteristics such as the electrical system, K15 manipulation, and more. The in-house developed remote lab (Figure 2) builds upon this basic infrastructure. The remote lab allows for targeted manipulation of the "device under development." A PicoScope completes the telemetry capabilities.

In the reference project, these infrastructure solutions enable tasks that developers perform daily, including long-term testing and mocking of hardware functions. This significantly simplified the coordination of the hardware-software interface. The reference feature board was commissioned using a simple Arduino sketch. Thus, the hardware behavior was known even before the development of the "Hardware Abstraction Layer" software component. This resulted in less effort in developing the subsequent software stack. Missing hardware features could be identified early and incorporated when updating the reference feature board.

architecture

All system-relevant decisions about the project must be made in the architecture. The architect's task is to fulfill the stakeholders' expectations of the project as far as possible. [R7] Together with the product owner/project manager, the "project environment" model (Figure 3, see) is used. PDF) the prioritizations in the product backlog (project planning) were carried out.

Agile projects also differ significantly from "agile but" or traditional projects in this respect. Debbie Madden cited one reason in 2014: "A true agile software development project can only define one side of a triangle. The other two sides must remain flexible. Otherwise, it is not a project that can be implemented using agile development." [R8] Therefore, project planning can only ever define one side and must continuously clarify the scope of the two remaining sides with the stakeholders.

In the reference project, this approach was implemented using an additive software architecture style. Continuous refactoring and maintenance enabled the addition of business requirements as coherent functional patterns. The system-relevant effort required for integrating these functional patterns must be kept constant throughout the project lifecycle. For example, extending diagnostics with a self-test does not necessitate a rewrite of the communication stack. Adding, replacing, and refactoring individual software features are therefore solely dependent on product backlog prioritization.

Development

The reference project uses two independent toolchains (Figure 4, see PDFSoftware tools from the upper toolchain are integrated into the automated Jenkins deployment pipeline. The same Jenkins instance is also used for the continuous testing pipeline.

The upper toolchain consists of standard-qualifiable software tools used for release effort in deliveries. Simplifying the ISO 26262 tool qualification requires that the upper toolchain does not rely on products from the lower toolchain. Software tools in the lower toolchain should have an ISO 26262 Tool Confidence Level of TCL 1 and are therefore exempt from tool qualification. [R9]

This separation means that lower-level software tools are selected solely based on their impact on the development environment. This allows methods like TDD and code hygiene to leverage the synergies of current open-source projects.

To meet the documentation requirements of safety-critical products, all architectural information is aggregated using the tool "Doxygen". Documentation that cannot be included in source code tags has been moved to Markdown files. To document requirements using this method, a strict proof of intent (linking) is required.

delivery

The additive software architecture style assumes consistent effort for functional pattern integration throughout the project lifecycle. Carola Lilienthal observed that changes to the source code increase technical debt (Figure 5, see...). PDF). [R10]

Technical debt comprises all expenses that are not part of the necessary implementation costs. Static analysis measures these using various metrics. Table 2 (see PDF) identifies the various causes of technical debt. Based on the analysis, different refactoring measures are derived. In contrast to the incremental waterfall/V model [R11], refactoring maintenance measures are expected for technical requirements.

In the reference project, technical debt was determined at the time of delivery. The architect, lead developer, and integrator assessed role-relevant technical debt. The goal of maintaining consistent integration effort was achieved. Necessary refactoring measures were therefore solely dependent on product backlog prioritization.

List of sources

 

Download the article as a PDF

---

Our training courses & coaching sessions

Do you want to bring yourself up to date with the latest technology?

Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.

Training & coaching on the other topics in our portfolio can be found here. here.

---

Quality, Safety & Security – Expertise

Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.

To the specialist information

You can find expertise on other topics in our portfolio here. here.