Software criticality level

The Software Criticality Index (SCI) refers to the index number obtained from the Software Criticality Level (SCL) matrix. It is essentially the SCL number, an index number (1 through 5) derived from the SCL matrix. This term is intended to replace the older term Software Hazard Risk Index (SHRI), primarily because the word risk in SHRI is misleading for the application. 

See Software Criticality Level (SCL) for additional related information. 

Establish the LOR tasks required for each SCL. Perform the LOR tasks on the software modules and document the evidence of successful completion (see Software Criticality Level [SCLf). This effort is done primarily by the software development organization. 

See Software Criticality Level (SCL), Software Safety (SwS), and Software Safety Program Plan (SwSPP) for additional related information. 

This subsection examines the data needed to perform a software reliability assessment with the models just described. In particular, we will define the concepts of criticality level and operational profiles. The complete list of data required by each model can be found in Table 21.5. 

Criticality The faults encountered in a software are usually placed in three or five categories called severity levels or criticality levels. This categorization helps distinguish those faults that are real contributors to software reliability from others such as mere enhancements. Such distinction is, of course, important... 

Standards such as RTCA DO-178B include the recommendation (depending on criticality level) to trace all code to requirements. In the absence of dynamic binding, this is relatively straightforward to achieve. Each procedure at the outermost layer of the software is typically present to support directly a stated functional requirement. Static analysis of the program can identify all lower-level procedures that are directly or indirectly called from the outermost procedures. Thus a lattice can be generated in which every procedure is directly or indirectly linked to one or more functional requirements. 

More than the half of the phases in our process are generic. Therefore, the techniques and tools used in these steps can be applied in various application domains. The domain-specific steps only differ in methods for the allocation of criticality levels to the system elements and the requirements for software verification validation. However, also common techniques and tools can be applied in these phases but have to be adapted to the domain-specific requirements respectively. There are only two process phases which are solely relevant to particular safety standards. For these steps domain-specific techniques and tools must be provided separately. 

In this paper, a method of software safety verification at the system level based on STPA is proposed. We investigated the application of the STPA structure to software, and we found that STPA can be directly used for software. We mapped the results of the STPA safety analysis to a formal specification to be able to verify safety requirements at the software code level. The limitation of the method is that the formal specification is done manually which may lead to much effort to construct and check the potential combinations of relevant states. Therefore, we are exploring the automation of this step and integrate it with our A-STPA tool as future work. Furthermore, we plan in-depth case studies to improve the method by applying it to real safety-critical software in industry. We plan also to investigate the effectiveness of using the proposed method during an ISO 26262 life cycle in the automotive industry. 

Systems aspects including the criticality levels, architecture considerations, user modifiable software. 

Each of the software quality processes/techniques described in the Standard is then listed (10 pages) and the degree to which they are required is indicated for each of the criticality levels A to D. The mapping is ... 

The SCL is an index number ranking the relative safety importance of a software module. This ranking implies that in order to make the software safe, greater development rigor must be applied to each successive criticality level. 

A low index number (i.e., 1) from the software criticality matrix does not mean that a design is unacceptable from a risk or safety standpoint. Rather, it indicates that a more significant level of effort is necessary for the requirements definition, design, implementation, and test of the software and its interactions with the system. 

A software validation plan must take into account the risk analyses for the software therefore a critical software must have a high level of confidence and must be submitted to deep validation processes, whereas noncritical software may be submitted to less extensive validation processes. 

The reason I include this seemingly irrelevant chapter in this book is because it is important. What are the factors that make a software project succeed One could say the project has to provide good business values. In addition, the project team has to be technically competent. Although these factors are all necessary for the project to succeed, they are not sufficient. Especially for a software project that has some level of complexity, tight timelines, and resource constraints, a good development process is also critical. Unless your development process is ad hoc, most likely you will use either the waterfall or the iterative development process. Many researchers show that the latter is a much better choice than the former, and many thoughtful leaders advocate its use in most software development projects. 

An assurance that the physical hardware, software, and the regulated electronic records are maintained in a secure environment is critical to the validated status of a computer system, particularly if it is an enterprise level system. Security must be instituted at several levels. Procedural controls must govern the physical access to computer systems (physical security). The access to individual computer system platforms is controlled by network specific security procedures (network security). Finally, application level security and associated authority checks control access to the computer system applications (applications security). 

---