If you are a SW Safety Engineer or a SW Engineer with practical hands-on experience in doing Safety activities, the Part-6 of the ISO26262 will be “Easy Peasy”. But if you are a Safety Engineer who never worked on SW but are asked to perform SW Safety Activities, then the Part-6 is surely “Tricky Dricky”!!
This article is targeted towards Safety Engineers who are unfamiliar with SW. We have taken a specific set of requirements from Clause 5 of Part 6 and attempted to simplify it. This is Part 1 of Clause 5, and we will do another Part-2 for the same clause.
Requirement 5.4.2 states the following:
5.4.2 The criteria that shall be considered when selecting a design, modelling or programming language are:
a) an unambiguous and comprehensible definition;
EXAMPLE Unambiguous definition of syntax and semantics or restriction to configuration of the development environment.
b) suitability for specifying and managing safety requirements according to ISO 26262-8:2018 Clause 6, if modelling is used for requirements engineering and management;
c) support the achievement of modularity, abstraction and encapsulation; and
d) support the use of structured constructs.
The big picture behind this requirement is the following: The ISO26262 does not recommend the use of any specific language for modelling or programming. Instead, it provides guidelines on how one should go about choosing the language. Typically, C or C++ is used for Programming and UML or MATLAB for design/modelling. These languages are well supported (by itself) to achieve some of the above-mentioned criteria. Wherever the language itself does not support these criteria, they must be supported by Guidelines and Tools.
Let us understand each of these criteria in more detail.
an unambiguous and comprehensible definition
Let us start with an example of a programming language.
“Unambiguous and comprehensible” means that every line of code and every function should give 1 clearly understandable meaning. To achieve this, a language must be used in such a way that it is syntactically and semantically correct.
What is meant by “Syntax” and “Semantics”?
Syntax refers to the Rules related to structure or the grammar of any sentence in the language (without considering correctness of meaning). For example,
• Every C or C++ statement ends with a semi-colon
• Enclose the conditional expression of an IF statement inside parentheses
Semantics refers to the meaning of the sentence in the language. Is the sentence valid and does it have a clear meaning?
A sentence may be syntactically correct but semantically not. Let’s take the “++” operator in C, which is used for incrementing variables. An operation “x++;” where ‘x’ can be a pointer, a character, an integer – are all syntactically correct.
If you execute “++” for an integer, it will increment the value by 1. But if you do the same for a pointer, it will increment the pointer to point to the next element of the same type. So, the result of a “++” for a pointer depends on the data type of the data that the pointer is pointing to. If you execute “++” for a character, it will increment the ASCII value of the character by 1.
The key is to ask the question “what was the intention behind doing the x++? ” if the intention was served well, then the sentence may also be semantically correct but if not, it will only be syntactically correct but semantically wrong.
Similarly, conversion from a function pointer to any other type is syntactically correct but semantically may not be.
This is where guidelines come into the picture and help to avoid some of the sematic errors. For e.g., MISRA Rule 11.3 in MISRA C 2012 Standard states that “Conversion shall not be performed between pointer to a function and any other type” because conversion of a function pointer to a pointer to an object leads to undefined behavior. But how would you manually check all the rules in the MISRA C standard? It is not possible. That is why there are static analysis tools in the market to do it.
Long story short, what the ISO26262 is saying is that when you choose a programming language, you must not only consider the capability of the language but also ensure that the language is supported by strong guidelines and tools that help to detect syntax and semantic errors.
The same applies for Modelling/Design languages as well. If you use UML or MATLAB, one thing is to use the language correctly by using the right symbols (the syntax) as per the specifications and the other thing is to look at the program/function holistically and evaluate if it is doing what it is really supposed to do using guidelines/tools, review checklists etc.
Suitability for specifying and managing safety requirements if modelling is used for requirements engineering and management
Typically, for decades, we have been using text for documenting requirements and there have been tools like DOORS, DNG, PTC etc which provided the required attributes such as ‘requirement description’, ‘ASIL level’, ‘Verification criteria’ ‘Allocation’ and required functionality to perform traceability or to track changes. Now, increasingly, as we are moving from the text world to the Modelling world for Requirement, the tools used for Modelling must support all the features needed for managing Safety Requirements such as
• Defining attributes such as ASIL level
• Verification method and criteria
• Upward and downward traceability
• Change Management
• Review Management
• Importing Requirements etc
Here is an example we found from Enterprise Architect, a tool that is quite often used for Modelling requirements. The below screenshot from EA demonstrates its feature set for supporting Requirements.
There are many other tools in the market that also support modelling of requirements.
Support the achievement of modularity, abstraction and encapsulation
What do these key words mean?
Modularity means dividing a complex system into smaller, independent modules that can be developed and tested individually, and then integrated into the overall system.
For e.g., C and C++ support modularity by letting us break down a complex SW into individual .c/.cpp files and then further break them down to multiple functions, each serving a specific purpose.
Abstraction is a process whereby we identify the important aspects of a phenomenon and ignore its details. It is like “generalizing” and ignoring the concrete aspects of how something is done.
For e.g., Function prototypes in C language provide an interface that abstracts the implementation details from the calling code. For e.g., “int add(int a, int b);” hides the implementation details of a and b are added.
Let’s take another example. The C library function void *memcpy(void *dest, const void *src, size_t n) is used for copying data between arrays or for duplicating data within the same array. This function is a perfect example of a generalization because it does not even care or know about the type of data that it is copying from a source to destination. For anyone who needs to copy from source to destination, it acts as a one stop interface.
Encapsulation refers to the practice of including within an object everything it needs, and furthermore doing this in such a way that no other object needs to be aware of this internal structure.
In one way it sounds very similar to abstraction. The focus of Encapsulation is to hide internal information while abstraction focusses much more on what is being generalized. The same example of memcpy can also be used to explain Encapsulation because it hides the Internal implementation details of memcpy.
Let’s take one more example from Autosar. The below Architecture diagram demonstrates the principles of Modularity, Abstraction and Encapsulation very well. It has broken down the overall functionality to smaller SW Components/Units each having a specific purpose, thereby demonstrating Modularity. From the perspective of Memory Services, the Memory Hardware and the supporting drivers are abstracted. Memory Hardware Interface provides the MemIf_Read() and MemIf_Write() interfaces that encapsulate all the underlying memory read/write implementation details.
To summarize, the programming and modelling languages must support these above principles. As stated for the previous criteria, the principles can fully be achieved with appropriate design, modelling and coding guidelines. For e.g., to ensure modularity, coding guidelines can have guidelines related to how to break down functionality to different files or functions. To support encapsulation, criteria can be related to how Interfaces should be defined in SW Components. Abstraction is much more of a design property that must be realized in SW Architecture, though it can also be carried out in Implementation level.
Support the use of structured constructs
A programming language should improve the clarity and quality of programs by providing means to have a structured control flow. An easy-to-read code will also be easy to understand, debug and most likely behave as it was intended.
It is possible to achieve a structure flow in the code by means of
• Ordered statements or subroutines executed in sequence
• Function name used to refer to a block of code
• Loops (For, While) for repetitive executions
• Selection (If, then, Else) for branched execution
Almost all programming languages support a control structure.
Conclusion
If you are a functional safety manager who wants to ensure that these principles are followed in the program
1. Have a SW Expert develop the Design, Coding and Modelling guidelines to ensure that a) unambiguous and comprehensible definition and c) modularity, abstraction and encapsulation are achieved.
2. Choose the right tools of SW development, such as ASIL compliant static analyzer tools and Compilers
3. Choose ASIL compliant Modelling tools for Requirements Management, Architecture and Unit Design
4. Follow Industry Best Practices like MISRA
5. Have project specific review guidelines for design, code and requirements to catch semantic errors