Safety Critical Software 1: Requirements and Architectures

1. Safety Critical Software 1:Requirements and Architectures

2. Contents • Scope of Software Requirements and architecture • Software requirements • Requirements problems • Requirements principles • Types of requirements • Requirements representations • Architecture and Design • Principles and problems • Notations and techniques • Production of architectures and designs • Architecture problems

3. Scope • Software requirements • Description of required software behaviour and integrity level • Complete definition for software engineer, so that there is no need to refer to other documents • Architecture • Software components and interfaces • COTS elements and their role in the system • Interfaces between components

4. Software Requirements • Requirements come from three main sources • Flow down from system (and platform) level • These are essentially requirements on the application • Derived requirements • From system hardware commitments • Validation of sensor data • Closed loop control for actuator • From computing hardware commitments • Management of processor board, e.g. interrupts • Derived safety requirements • Functional requirements on individual components • Rate of occurrence of failure modes, e.g. omission of function • Arise from functional failure or flow-based analysis (HAZOP) NB unsafe if software model of state of world differs from reality

5. System Decomposition and Requirements

6. System Decomposition and Requirements

7. System Decomposition and Requirements

8. System Decomposition and Requirements

9. Requirements and Sources

10. Problems with Requirements • Assumptions • Omissions where “it is obvious that ...” • Control performance specified by point values • “it is obvious that” the behaviour is linear in between • Apart from the mode change …! • Ambiguity and incompleteness • “alarm when the average level < X for more than four seconds” • average = mean, mode, …? • four seconds continuously, over a minute, …? • When is the alarm cancelled? • Excessive detail • Algorithms, e.g. control law diagrams or code, but no specification of inputs, intent ...

11. Specific Principles R1 Notations must be intelligible to all stakeholders to support production and validation R2 Requirements must enable analysis of consistency and completeness, and facilitate hazard analysis R3 Notations must support the statement of requirements on software embedded in a system context R4 Notations must be capable of expressing all the types of requirements placed on the software R5 Requirements must be traceable to implementation

12. Types of Requirements (R4) General classification - not just for safety • Invariants - properties which always hold • Roadside and trackside signals won’t be green at the same time • Sometimes qualified with an acceptable failure probability • Functional - transform inputs to outputs • Calculate train speed from axle rotation using the formula … • Event response - action on (exceptional) event • A klaxon will be sounded in the cab if the train passes a red light • Non-functional (NFRs) - often constraints on others • A klaxon ... within 1 second of the train passing a red light • NFRs often timing, resource usage, etc.

13. Example Safety Requirements (of each type) • Invariant • e.g. difference in number of missiles on wings  1 (CofG control) • Flows down from system or hazard analysis • Functional requirements • e.g. where safe  correct behaviour, such as flying control system • Flows down from system or hazard analysis • Event response requirements • e.g. function to detect and mitigate hardware failure • Usually comes from safety process, e.g. FMEA • Acceptable rates of occurrence of hazardous failure modes • e.g. omission of command to set signal to red • Usually flow down from system safety analysis (PSSA)

14. Stating Requirements: Natural Language • Very widely used • Often supplemented by diagrams and formulae • Meets R1 and R4 • Not R2 and no real support for R3 or R5 • Structured (controlled) natural language • Subset of English or other language • Constrained sentence structure • Or use of tabular requirements • Often use of restricted vocabulary • Better with respect to R2, but still difficulties of ambiguity • Quite widely used - some tool support, e.g. DOORS • Can use natural language templates for consistency • can help, but don’t avoid ambiguity

15. Software Cost Reduction • SCR devised in response to natural language problems • Specify precisely what must be built • Document results for communication • Addresses R1, R2, R3 • Aimed at high assurance systems • Large, complex, embedded • Expensive and difficult to build correctly • Software with real-time constraints (although timing not explicit) • Require temporal as well as logical correctness • Correct software delivers results within real-time limits • Software that is safety / mission critical • High cost of failure lead to high cost of verification

16. Basis: Four Variable Model • Monitored variables • Quantities measured, real world values, e.g. ‘aircraft on ground’ • Input variables • Data for evaluating monitored variables, e.g. weight on wheels • Output variables • Means to affect controlled variables, e.g. current to solenoid • Controlled variables • Quantities affected, e.g. lights, position of points • System Requirements • Controlled variables in terms of monitored variables (not inputs) • Software Requirements in terms of inputs and outputs

17. Four Variable Model:Requirements Relationships • A complete Four Variable specification defines all observable required (functional) behaviour • Specified in mode, condition and event tables Monitored Variables System Controlled Variables Environment Input Devices Software Output Devices Environment Input Data Items Output Data Items IN SOFTREQ OUT REQ and NAT

18. SCR Table Types • Mode tables • A mode is an abstract state, where different functions are available from other modes • Describes a mode as a function of a(nother) mode and an event • Analogous to finite state automata • Provide a frame for the remainder of the specification • Condition Tables • Describes an output variable or term as a function of a mode and a condition • Event Tables • Describes an output variable or term as a function of a mode and an event

19. UML and SysML • Visual language for specifying, constructing, and documenting artefacts of software systems • SysML represents a subset of UML 2.0 with extensions needed to satisfy the requirements of the UML for Systems Engineering • SysML and UML • Requirements diagrams • Graphical construct to represent text based requirements • Capture requirements hierarchy, derivation, satisfaction, and refinement

20. Architecture and Design • Architecture • Art and science of constructing edifices for human use (OED) • In software engineering • The (art and science of constructing) large scale structure of a system, showing the relationship of the major parts (components) • Design • The preliminary conception of an idea which is to be carried into effect (OED) • In software engineering • The preliminary conception for the elements of the system (components) identified in the architecture • In practice, very strong links, and methods often don’t distinguish the roles

21. Scope of Architecture • Software architecture is multi-faceted • Have previously focused on physical and functional hierarchies • These are still relevant • Other facets of interest • Module hierarchy (the parts we build the code out of) • Will not (necessarily) be the same as the function hierarchy • Dynamic structure • Scheduling and tasks / processes (if used) • Timing • Especially with control systems • Software to hardware mapping • Especially in distributed systems • But also covering issues such as memory mapped devices • Historically not well modelled • Limited support in notations such as Sys-ML

22. Software Layering • Implements SOFTREQ • Implements I/P & O/P • Validated sensor dataand actuator control • Fault management • To produce “trusted” data for application • NB hazard if softwareview of world differsfrom reality • Abstraction from processing hardware • Operating system

23. Production of Architectures • Developing architectures is a creative process • No “mechanical” rules, but “patterns” growing in popularity • We can learn from past experience • Most design is a “repeat” or variant of earlier work • Current work on supporting “repeat” design effectively • Patterns of “commonly occurring” design structures • Product-line architectures • Representing commonalities and variabilities between members of a family, e.g. set of level crossing controllers • Common parts (in every member of the family) • Optional parts (variabilities) • Rules for the “correct construction” of instances from patterns • May be possible to produce family safety process • Current area of research

24. Problems • Architecture often not specified adequately • May be no architecture at all • Many organisations talk about “requirements flow down” • Miss out the critical step of structuring the design • Architecture often specified incompletely • Functional decomposition, but little else • e.g. no definition of responses to external stimuli (transactions) • Software architecture compromised by system design • Where most of functionality is in software, system architecture and software architecture will have very similar structures • If software issues not considered at system level, software may be inefficient, hard to modify, hard to schedule • Software architecture not a basis for predicting properties of implementation • Safety, timing cannot be inferred from description

25. Analysis of Architectures • Four main aspects of analysis • Showing internal consistency and completeness • Verifying that design is consistent with requirements • May not be enough information to fully show it meets requirements • Generally done by review, or simulation • For example, employing use cases as test scenarios • Predicting that implementation will be satisfactory • e.g. fit into constraints of memory, CPU time, etc. and still meet requirements • Based on estimate of code execution time etc. • Assessing safety • i.e. ensuring that potential software-caused contributions to failure are acceptable • Or driving out further DSRs to deal with problems • Techniques such as HAZOP are relevant

26. Observations • Many approaches to producing requirements • All methods have strengths and weaknesses • e.g. SCR forces rigour without being too overtly mathematical, but does not address invariants or NFRs • Architecture and high-level design is important • If done well • Limited lower level analysis needed • No new hazardous failures should be found at lower levels • Lower project risk than otherwise • Signs of poor architecture • Single faceted • e.g. functional decomposition, but no mapping to hardware • Inability to analyse for consistency, etc.