4.4
Property-Based Specification of IA System-Level Requirements
At the next level are the system-level requirements and system architecture definition. The system design process establishes the boundaries and the context of system and further decomposes the sys- tem and into major subsystems and their interfaces. These include the IA system, on-board avionic subsystems, human pilot, cockpit displays, instruments, additional devices, and external actors such as ground stations and air traffic control (ATC). Absent such specifications about the system, one can- not rigorously discuss the implications of introducing an IA system in the control loop. For instance, without knowing how the pilot is going to communicate with the IA system, one cannot explore the advantages, failure modes and assurance strategies to guarantee smooth communication between the pilot and the IA system. System requirements drive the downstream activities of the development and verification of hardware/software components.
In this section we identify exemplars of system-level requirements that will satisfy stakeholder re- quirements. We first present a property-based requirements specification approach that allows the capture of key functional properties and attributes of the IA system especially from the perspective of design assurance. Next, we define examples of property-based specifications across the spectrum of the different categories of IA system functions. It is noted that the scope of this report is to identify examples across the functional spectrum to properly inform the assurance and safety considerations.
4.4.1 Property-Based Requirements
A well-defined set of requirements is considered to be a necessary prerequisite for efficient and ef- fective communication between the users, requirements engineer, and the designer/constructor of the system. Most system requirements are often written in natural language since it can be easily written, read and understood by variety of stakeholders such as pilots, engineers, developers and certification agencies. However, despite all efforts they are vague, interpretable and dependent on the subjectivity of the author as well as the reader [37,93]. To improve this situation, requirements must be objectified, i.e. rendered precisely and be understood in the same way by all stakeholders concerned [93,95]. A variety of notations and languages to capture requirements, in both formal and informal means, were developed to achieve the desired level of precision and specificity.
Pure formal notations such as linear temporal logic are highly precise and are amenable to rigorous formal analysis and assurance. But they lack the ease and understandability of natural language and, more importantly, the requirement authors have to be highly skilled to write, and validate the require- ments. To partly address this challenge, recent work such as ModelWorks [88] and Requirements Specification Language (RSL) [55] have attempted to capture requirements in formal notation, but with a slight natural language flavor. They also provide set of tools to perform a variety of automated analysis on the requirements. However, they still require some level of mathematical and formal logic skill to employ them.
4 SAFETY RELEVANT REQUIREMENTS IN IA SYSTEMS
To leverage the advantages of both natural language and formal notation, we propose a property based requirements notationthat uses a controlled, structured natural language to specify behaviors of a system in an intuitively understandable yet unambiguous manner. Such a structured notation is amenable to machine interpretation and thus enables the transparent use of back-end automation tools to generate formal specification to enable downstream V& V and assurance activities.
Property based requirements (PBR) method is a way to specify requirements as a set of properties of system objects in either structured language or formal notations. The idea of PBR was first proposed by Dr. Patrice Micouin [94]. PBR exist within a model-based system design methodology, termed the Propriety Model Method (PMM) [95]. PBR are always passive, observable statements on system properties; a well-formed requirement is “a constraint applied to a property of the system when a condition or event occurs or a state is achieved”.
This notation focuses on capturing the properties of the system. System properties can either be spec- ified as a combination of relational, mathematical and/or logical operations over objects of the system (constraints), or as a causal relationship between desired system behaviors and its causes (triggers and preconditions). This notation provides keywords such as ‘While’ and ‘Where’ to allow users distinguish between requirements about a specific state of the system or with a specific configuration (or enabled feature) respectively. Similarly, keywords such as ‘When’ and ‘If’ allow users to distin- guish normal operational requirements from abnormal situation requirements. Further, this notation provides a set of relational, mathematical, logical and intent based constructs in a natural language form that helps standardize the way the system behaviors and causes are captured, yet be intuitive to the users.
PBR serve the role of clearly delineating the context and behaviors of the IA system in terms of well- defined system objects and their properties. This is crucial in our context since the tasks performed by pilots draw from accumulated learning from multiple source: standard operating procedure (SOP), formal education and training, total flight hours, knowledge of operating the aircraft, experience handling situations at various levels of emergency, and general common sense and intuition. Thus, the requirements for many of a pilot’s tasks and behaviors are implicit, centered on the pilot’s “model of the world”. When specifying requirements for the IA system, one needs to explicitly define the machine’s “model of the world” and specify properties that are grounded to specific entities in that model. Within the scope of this report, we do not attempt to define this model but provide examples of properties that would be specified.
In addition to facilitating requirements specification in the manner stated above, PBR enable a flex- ible and rigorous approach to design assurance and safety analysis. Verification and validation can be performed for certain properties at design time and for certain other properties using run time monitoring techniques. Notion of independent properties that are strongly tied to system objects lend similar flexibility in the definition of assurance cases. Section3contains more details on the assurance considerations.