The ISO Standard specifies several methods on how to do Safety Software Architecture. These principles are generically stated. But most often these are not clear:
- Why are these principles defined?
- How do we ensure which principles we have achieved?
- Have we achieved the principle sufficiently?
For e.g., for a principle that states "restricted size of interfaces', why do I need this rule and how restricted should the size be? In this article, we first explain why these principles are needed in the context of Safety, and then propose a set of questions for each principle. These questions aim to act as a checklist to determine if the principle has been sufficiently satisfied. Assuming that most Organizations have well-defined guidelines for software architecture and the lessons learnt and best practices based on the experience from previous projects, these questions are intended to guide the architect or the reviewer of the architecture to think if all possible aspects have been sufficiently covered, and if there is still scope for improvement.
These are the principle defined by the Standard on how to do a Safety software architecture.
(Ignore the number that you see at the far end of each principle)
In a nut shell, all these principles are aimed at keeping the system "simple and stupid". Note that these are all very useful guiding principles for not only safety but overall architecture. For e.g., have a restricted size and complexity of software components, strong cohesion within the component etc aims to keep every software component focused on a specific-well-defined purpose, and not bringing in too many functionalities into a single component, thus keeping it simpler. Which also means, less complex and far more feasible to test all scenarios. Principles like loose coupling, and restricted size of interfaces also support the above aim by targeting to limit the interaction of a component with other components. A hierarchical architecture sets rules for communication, and thus restricts which components can communicate to a safety relevant component, and how they can do so, thus bringing in more consistency in the design. Principles like restricted use of interrupts, and appropriate scheduling properties enable to make the system much more dependable and deterministic. Lastly, principles like spatial isolation and management of shared resources are aimed to achieving freedom from interference for Safety functionalities from Non-safety Software.
Now, let us go over to the checklist.
Appropriate Hierarchical structure of software components
Restricted size and complexity of software components
Restricted size of Interfaces
Strong Cohesion within each software component
Loose coupling between software components
Appropriate scheduling properties
Restricted use of Interrupts
Appropriate spatial isolation of the software components
Appropriate management of shared resources
Now that we have a checklist, what are the possible next steps? Here are few ideas on how to use it:
- Apply the checklist for your existing Safety architecture, for e.g., as part of the review process, and identify possible avenues for improvement
- Define additional guidelines/rules to ensure that the principles will always be met without the need for a explicit verification.
- Use it as a base to define some quantitative metrics to measure if the principles have been achieved sufficiently. These metrics need not necessarily be a one-size-fits-all, but it can customized depending on the type of architecture, the layer in which the component fits etc.