Certifiable Software Applications 1

Main Processes

Jean-Louis Boulanger

• Publisher: ISTE Press - Elsevier
• Year: 2016
• Print ISBN: 9781785481178
• eBook ISBN: 9780081011652
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

Certifiable Software Applications 1: Main Processes is dedicated to the establishment of quality assurance and safety assurance. It establishes the context for achieving a certifiable software application. In it, the author covers recent developments such as the module, component and product line approach. Applicable standards are presented and security principles are described and discussed. Finally, the requirements for mastering quality and configuration are explained. In this book the reader will find the fundamental practices from the field and an introduction to the concept of software application. - Presents the fundamental practices from the field - Emphasizes the development of quality assurance and safety assurance - Introduces the concept of software application - Covers recent developments such as module, component, and the product line approach

1

System, Equipment and Software

Abstract:

It is impossible to speak of software without referring to the system; in fact software does not exist without at least one execution platform that involves equipment and this equipment is integrated into a system. Contrary to popular belief, software is seldom reusable, generic or independent.

Keywords

Command; Control system; Dedicated; Dependability; Equipment; Generic; Safety; Software application; Specific; System

1.1 Introduction

It is impossible to speak of software without referring to the system; in fact software does not exist without at least one execution platform that involves equipment and this equipment is integrated into a system. Contrary to popular belief, software is seldom reusable, generic or independent.

Very often, only one of the listed properties of the software is related to its independence with regard to the rest of the system; therefore, it may seem easy to modify just this one property; however, this is a gross miscalculation, as a software version is validated for a particular version of equipment and thus any change requires revalidation and analysis of impacts with respect to the equipment and the complete system.

The first chapter aims to put the software in the context of user equipment or systems and thus to reiterate the relationships and constraints that must be taken into account to develop a piece of software.

1.2 Impact on dependability

Automation of a number of command systems (railways, aerospace, automotive, etc.) and/or process controls (production, etc.) and replacement of poorly-integrated digital or analog systems (based on relay, for example) with high integration systems have led to a considerable expansion in the field of system dependability while taking into consideration the characteristics and specificities of computer systems.

Dependability [LAP 92, LIS 96, VII 88] involves four characteristics – reliability, availability, maintainability and safety (these concepts are discussed in Chapter 3).

The system safety includes applications which necessitate proper continuous operation, either due to the human lives involved (transport, nuclear, etc.) or due to the high investments at stake in the event of a calculation failure (space, chemical production process, etc.), or even due to the cost of inconvenience that could be caused due to failures (banking process, reliability of transport, etc.). It must be noted that in recent years, there is also a consideration of the impact on the environment.

Though system safety is an important subject which is always at the forefront, the other three subjects (RAM: Reliability, Availability and Maintainability) are just as important and may require great efforts. Let’s take the example of maintenance; it is necessary to provision for maintenance from the time of designing (for example, consider dismantling capacity), and continue maintaining the system until its deactivation. Deactivation (Figure 1.1) does not mean the removal of the system, but decommissioning followed by a complete decommissioning of mall the system parts.

Figure 1.1 Lifecycle of a system

In the context of Figure 1.1, the maintenance phase concerns all the elements of the system. The software is a unique component as it is quite easy to modify and produce a new version, and it is presumed that its maintenance must be easy as well.

Software maintenance requires skills (trained personnel), means (machines, operating systems, tools, etc.), procedures and complete documentation of software and sources.

From the early stages of study (Figure 1.1 – requirement analysis) of such systems, the problems related to validation have always been a main concern of the designer: proper designing of mechanisms enable to respond to failures, to verify the design (simulations, tests, proofs, etc.) and to estimate, in a convincing manner, the relevant magnitudes measuring dependability performances.

1.3 Command and control system

Figure 1.2 shows an example of a rail system. The Operation Control Centre (OCC – top left picture¹) allows control over the entire line and sends commands to the trains as well as to the signaling management system (bottom left picture represents a manual operation control center).

Figure 1.2 The system in its environment²

The operation control center³ sends commands to the field through a set of relays (bottom middle picture shows an example of a room containing the relays associated with the signaling). In response to the commands, the field equipment adopts the required behavior (bottom right photo shows the operating signals).

Figure 1.2 introduces the complexity associated with the concrete system and it demonstrates that a complex system is not based on software, but on equipment that contains one or more pieces of software. Each of these programs is associated with safety objectives that can be different.

The software involved in supervision activities does not have as much impact on the safety of people as the software related to the automated control of trains. Therefore, in the context of systems requiring certification (aviation, railways, nuclear, programmable electronic based system, etc.), a safety level [BOU 11b] is associated to each software. This safety level is associated with a scale ranging from non-critical to high criticality. The concept of safety levels and the scales are discussed in Chapter 7.

Figure 1.3 helps to identify that the system to be developed is related to an environment that reacts to commands. It is, therefore, necessary to acquire a vision of the process s...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Introduction
• 1: System, Equipment and Software
• 2: Software Application
• 3: Principle of Dependability
• 4: Safety Management of a Software Application
• 5: Safety of a Software Application
• 6: Technique to Manage Software Safety
• 7: Assessment and Certification
• 8: Different Sectors and Various Normative Referentials
• 9: Quality Management
• 10: Requirement Management
• Conclusion
• Bibliography
• Index