Requirements State Machine Language Research Articles

Specifying and Analysing System-Level Inter-Component Interfaces

In control systems, the interfaces between software and its embedding environment are a major source of costly errors. For example, Lutz reported that 20% 35% of the safety related errors discovered during integration and system testing of two spacecraft were related to the interfaces between the software and the embedding hardware. Also, the software’s operating environment is likely to change over time further complicating the issues related to system-level inter-component communication. In this paper we discuss a formal approach to the specification and analysis of inter-component communication using a revised version of RSML (Requirements State Machine Language). The formalism allows rigorous specification of the physical aspects of the inter-component communication and forces encapsulation of communication related properties in well defined and easy to read interface specifications. This enables us to both analyze a system design to detect incompatibilities between connected components and use the interface specifications as safety kernels to enforce safety constraints.

Independent validation and verification of the TCAS II collision avoidance subsystem

This paper describes the specification-based testing, analysis tools, and associated processes used to independently validate, verify, and ultimately, provide for certifying safety-critical software developed for the Traffic Alert and Collision Avoidance System (TCAS II) program. These tools and processes comprise an effective and Independent Validation and Verification (IV and V) activity applied to the Collision Avoidance Subsystem (GAS) software development process. A requirements specification language called the Requirements State Machine Language (RSML), originally developed by the University of California, Irvine (UCI), was employed for the specification of GAS. The end result is the next generation of TCAS II collision avoidance logic, referred to as Version 7, that is of a higher quality than its predecessors, meets the certification requirements of DO-178B Level B (Ref. 1), and can be shown to satisfy the new operational requirements it was developed to address.

On the analysis needs when verifying state-based software requirements: an experience report

In a previous investigation we formally defined procedures for analyzing hierarchical state-based requirements specifications for two properties: (1) completeness with respect to a set of criteria related to robustness (a response is specified for every possible input and input sequence) and (2) consistency (the specification is free from conflicting requirements and undesired nondeterminism). Informally, the analysis involves determining if large Boolean expressions are tautologies. We implemented the analysis procedures in a prototype tool and evaluated their effectiveness and efficiency on a large real world requirements specification expressed in an hierarchical state-based language called Requirements State Machine Language. Although our initial approach was largely successful, there were some drawbacks with the original tools. In our initial implementation we abstracted all formulas to propositional logic. Unfortunately, since we are manipulating the formulas without interpreting any of the functions in the individual predicates, the abstraction can lead to large numbers of spurious (or false) error reports. To increase the accuracy of our analysis we have continually refined our tool with decision procedures and, finally, come to the conclusion that theorem proving is often needed to avoid large numbers of spurious error reports. This paper discusses the problems with spurious error reports and describes our experiences analyzing a large commercial avionics system for completeness and consistency.

Designing specification languages for process control systems

Previously, we defined a blackbox formal system modeling language called RSML (Requirements State Machine Language). The language was developed over several years while specifying the system requirements for a collision avoidance system for commercial passenger aircraft. During the language development, we received continual feedback and evaluation by FAA employees and industry representatives, which helped us to produce a specification language that is easily learned and used by application experts. Since the completion of the RSML project, we have continued our research on specification languages. This research is part of a larger effort to investigate the more general problem of providing tools to assist in developing embedded systems. Our latest experimental toolset is called SpecTRM (Specification Tools and Requirements Methodology), and the formal specification language is SpecTRM-RL (SpecTRM Requirements Language). This paper describes what we have learned from our use of RSML and how those lessons were applied to the design of SpecTRM-RL. We discuss our goals for SpecTRM-RL and the design features that support each of these goals.

Experiences and lessons from the analysis of TCAS II

This report highlights some of the experiences gathered while analyzing the requirements specification for a commercial avionics system called TCAS II (Traffic alert and Collision Avoidance System II) for consistency and completeness. Completeness in this context is defined as a complete set of requirements, that is, there is a behavior specified for every possible input and input sequence.Under the leadership of Dr. Nancy G. Leveson, the Irvine Safety Research Group has developed a state-based requirements specification language RSML (Requirements State Machine Language) using TCAS II as a testbed [6]. The TCAS requirements specification project was very successful; RSML was well liked by all participants in the project, and the formal specification has been adopted as the official TCAS II requirements. The requirements document has been delivered to the FAA and has undergone an extensive independent validation and verification effort (IV&V).In a previous investigation, we defined procedures for analyzing state-based requirements specifications for completeness and consistency [5]. To demonstrate that our approach is feasible and is applicable to realistic systems, we have implemented a draft analysis tool and we have applied the analysis to the TCAS II requirements. The initial results from the analysis effort were encouraging [4, 5] and scaled well to a large requirements specification. The most complex parts of the TCAS requirements specification have recently been analyzed. Even though the effort was largely successful, some limitations with the approach have surfaced. Most importantly, the accuracy of the analysis algorithms needs improvement. When analyzing the most complex parts of the TCAS requirements, the number of spurious error reports can occasionally be overwhelming. Furthermore, we discovered that once the analysis has identified problems, it has been unexpectedly difficult to correct some of them.

REQUIREMENTS FOR DEVELOPMENT OF SOFTWARE REQUIREMENTS

AbstractThis paper (1) describes what the current literature identifies as qualities of good software requirements, (2) identifies and examines different categories of software requirement methods, and (3) concludes that methods used to develop software requirements, though not perfect, have advantages that can improve the development of requirements for any type of system. Twelve requirement qualities were identified from the literature and these were used to establish evaluation criteria for software requirement development methods. Three methods selected for evaluation were the Hatley‐Pirbhai method (1988), the CoRE (Consortium Requirements Engineering, SPC, 1992), and Requirements State Machine Language (RSML) develop by Leveson (1990). None of these method stands out as being superior and each have strengths and weaknesses depending upon the application, but each offers improvements over the text based methods used in traditional systems engineering efforts to create function/requirement sets.