Advertisement

Master the unending software development lifecycle of connected systems—or it will master you

September 07, 2018

MarkPitchford-September 07, 2018

If you’re developing safety-critical software, you understand the importance of bi-directional requirements traceability to ensure that the design reflects the requirements, that the software implementation reflects the design and that the test processes confirm the correct implementation of that software. You also know how painful requirements changes can be because of the need to identify changing code and any testing to be repeated.

Until now, that cycle has concluded with product release. Sure, there might be tweaks in response to field conditions but the business of development was essentially over. Then came the connected car, the Industrial Internet of Things (IIoT) and the remote monitoring of medical devices. For these and other connected systems, requirements don’t just change in an orderly manner during development. They change without warning, whenever a bad actor finds a new vulnerability or develops a new hack. And requirements keep on changing not just through the lifetime of the product, but as for long as it is in the field.

Whenever changes become necessary, revised code needs to be reanalyzed statically and all impacted unit and integration tests need to be re-run (regression tested). In an isolated application, the time to support such occurrences lasts little longer than the time the product is under development. But connectivity demands the ability to respond to vulnerabilities identified in the field. Each newly discovered vulnerability implies a changed or new requirement, and one to which an immediate response is needed—even though the system itself may not have been touched by development engineers for quite some time. In such circumstances, being able to isolate and automatically test only the functions impacted becomes much more significant.

This changes the significance and emphasis of product maintenance and adds new importance to automated requirements traceability tools and techniques. By linking requirements, code, static and dynamic analysis results and unit- and system-level tests, the entire software development cycle becomes traceable, making it easy for teams to identify problems and implement solutions faster and more cost effectively—even after product release. This offers developers a vital competitive advantage when the dreaded message “we’ve been hacked” arrives.

Process Objectives and Phases

We’ll use the ISO 26262 automotive functional safety standard as an example, but the same principles apply to other safety-critical industries and standards such as DO-178C, IEC 61508 or IEC 62304. Although terminology varies, a consistent element is the practice of allocating technical safety requirements in the system design specification and developing that design further to derive an item integration and testing plan. It applies to all aspects of the system, with the explicit subdivision of hardware and software development practices being dealt with as the lifecycle progresses. The relationship between the standard and the software specific sub-phases can be represented in a V-model (see Figure 1).

click for larger image

Figure 1 - Software-development V-model with cross-references to ISO 26262 and standard development tools. (Source: LDRA)

System Design

The products of the system-wide design phase can include CAD drawings, spreadsheets, textual documents and many other artifacts, produced using a range of tools. This phase also sees the technical safety requirements refined and allocated to hardware and software. Maintaining traceability between these requirements and the products of subsequent phases generally causes a project management headache.

The ideal tools for requirements management can range from a simple spreadsheet or Microsoft Word document to purpose-designed requirements management tools such as IBM Rational DOORS Next Generation or Siemens Polarion REQUIREMENTS. The selection of the appropriate tools will help in the maintenance of bi-directional traceability between phases of development.

Specification of Software Safety Requirements 

This sub-phase focuses on the specification of software safety requirements to support the subsequent design phases, bearing in mind any constraints imposed by the hardware. It provides the interface between the product-wide system design standard and software-specific requirements and details the process of evolution of lower level, software-related requirements. It will likely continue to leverage the requirements management tools used in the system design phase.

Software Architectural Design

There are many tools available to generate the software architectural design, including MathWorks Simulink, IBM Rational Rhapsody and ANSYS SCADE. Static analysis tools help verify the design by means of control and data flow analysis of the code derived from it, providing graphical representations of the relationship between code components for comparison with the intended design (see Figure 2).

click for larger image

Figure 2 - Graphical representation of control and data flow as depicted in the LDRA tool suite. (Source: LDRA)

Software Unit Design and Implementation

The illustration in Figure 3 is a typical example of a table from ISO 26262-6:2011. It shows the coding and modelling guidelines to be enforced during implementation, superimposed with an indication of where compliance can be confirmed using automated tools.

click for larger image

Figure 3 - Mapping the capabilities of the LDRA tool suite to “Table 6: Methods for the verification of the software architectural design” specified by ISO 26262-6. (Source: LDRA)

These guidelines combine to make the resulting code more reliable, less prone to error, easier to test and easier to maintain. Peer reviews represent a traditional approach to enforcing adherence to guidelines, and although they still have an important part to play, automating these tedious checks is far more efficient, repeatable and demonstrable, and is less error-prone. There are many sets of coding guidelines available, such as MISRA, in-house sets, or adaptations to a standard set to make it more appropriate for a particular application (Figure 4).

click for larger image

Figure 4 - Highlighting violated coding guidelines in the LDRA tool suite. (Source: LDRA)

Establishing appropriate project guidelines for coding, architectural design and unit implementation are three discrete tasks but software developers responsible for implementing the design need to be mindful of them all concurrently. The guidelines relating to software architectural design and unit implementation are founded on the notion that they make the resulting code more reliable, less error-prone, easier to test and easier to maintain.

click for larger image

Figure 5 - Output from control and data coupling analysis as represented in the LDRA tool suite. (Source: LDRA)

Static analysis tools can provide metrics to ensure compliance with the standard, such as complexity metrics as a product of interface analysis, cohesion metrics evaluated through data object analysis and coupling metrics via data and control coupling analysis (Figure 5). Static analysis can also ensure that the practices required by standards are adhered to whether they are coding rules, design principles or software architectural design principles. In practice, the role of such a tool often evolves from a mechanism for highlighting violations to a means to confirm that there are none.

Continue reading on page two >>

 

< Previous
Page 1 of 2
Next >

Loading comments...