UK Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment, 1991. Interim Defence Standard 00-55/Issue 1.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....to Ada, and may not be applicable to other languages. 6 . The work by York Software Engineering, British Aerospace and the U.K. Ministry of Defence [Hutcheon 1992] is specific to safety critical applications with emphasis on the military requirements of the INTERIM Defence Standard 00 55 [UKMoD1991] Two levels of requirements are defined (i.e. one to represent mandatory and the other optional features that a language should have) and subsequently used to assess Ada9X in [Hutcheon 1992] The level one, mandatory requirements are L1 A high integrity software language must be ....

U.K. Ministry of Defence, The Procurement of Safety Critical Software in Defence Equipment, INTERIM Defence Standard 00-55 (PART 1: REQUIREMENTS)/Issue 1, 5 April 1991.

.... and safety critical software, 3] and [5] It is, however, widely recognised that other aspects of the development process play at least as important a role as formal techniques in determining the integrity of a system; for example, the UK defence standard for developing safety critical software [33] places a strong emphasis on the qualifications and experience of the people involved in a development; the independence of the Auditors; the separation of the Design and Verification and Validation teams; and the production and control of documentation. Furthermore, it is widely recognised that ....

Ministry of Defence. The Procurement of Safety-Critical Software in Defence Equipment, 1997. Defence Standard 00-55.

....a Z specification. It is supported by a suite of tools for checking the consistency and correctness of the development. These tools have been used in the production of this paper. INTRODUCTION A number of standards for the development of safety critical systems, most notably IDS 00 55 [1][2], call for the use of formal methods. Whilst there has been some examples of the use of such techniques, e.g. the SACEM project [3] they have not been widely adopted despite the level of assurance which they potentially offer. There are a number of reasons commonly given for this, including the ....

Ministry of Defence, The Procurement of Safety Critical Software in Defence Equipment. INTERIM Defence Standard 00-55 (PART 2: GUIDANCE)/Issue 1. Ministry of Defence (5th April 1991).

....a Z specification. It is supported by a suite of tools for checking the consistency and correctness of the development. These tools have been used in the production of this paper. INTRODUCTION A number of standards for the development of safety critical systems, most notably IDS 00 55 [1][2] call for the use of formal methods. Whilst there has been some examples of the use of such techniques, e.g. the SACEM project [3] they have not been widely adopted despite the level of assurance which they potentially offer. There are a number of reasons commonly given for this, including ....

Ministry of Defence, The Procurement of Safety Critical Software in Defence Equipment. INTERIM Defence Standard 00-55 (PART 1: REQUIREMENTS)/Issue 1. Ministry of Defence (5th April 1991).

....inadequacies, like violation of deadlines and overload. There are yet again, other methods that can complement formal methods with verification of timing, e.g. execution time analysis [Pus89] and scheduling [Ram90,Xu90] There are standards that advocate the use of formal methods. For example, [MoD95, MO178B, IEC1508]. Formal methods are no silver bullets. They are not the single solution. Formal methods in general, like other informal methods (SA SD, OOA OOD) does impose discipline on the users and make them think in rational and disciplined ways helping to increase understandability, finding problems and ....

Ministry of Defence UK. The Procurement of Safety Critical Software in Defence Equipment. Draft Defence Standard 00-55, August 1995.

....7. 2 Annotated bibliography The following list is not intended to be definitive, but gives some pointers to useful literature on the use of formal methods: ffl Use of formal methods on Safety Critical Systems: 2, 6, 7] ffl Standards calling up formal methods: [29, 30] ffl Case studies of applications of formal methods: 8, 11, 19, 23] ffl Industry experience reports: 14, 16, 17, 34] ffl Reference books on particular formal methods: Z [33] VDM [21] B [1, 24] Object Z [12] for object oriented specifications refinement of specifications to ....

U.K. Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment. Defence Standard 00-55, August 1995. http://www.dstan.mod.uk.

....constraints of individual components, and to introduce internal timing constraints during system refinement. 1 Introduction The need for formal methods in the development of safety critical software systems is now well accepted. Current standards for the development of such systems (e.g. [2, 7, 15]) mandate the use of formal methods for high levels of safety assurance. Most safety critical systems are embedded systems which can cause harm (i.e. loss of life or injury) by failure to correctly interact with their environment. Since such failures are often of a time related nature, there is a ....

U.K. Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment, August 1995. Defence Standard 00-55.

.... with software development, including inter and intra document dependencies, which is called Configuration Management(CM) Regulatory and standards authorities have long recognised the importance of reliable SCM mechanisms, especially in the development of high integrity software systems [3, 4, 5, 17]. Version Control(VC) is an important supporting technology for SCM. VC concerns storage and retrieval of different versions of development components. Most VC systems attempt to maintain a record of the changes ( deltas ) between different versions of components. This provides the basis for ....

U.K. Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment. Defence Standard 00-55, August 1995.

.... configuration of versions of documents associated with software development, including inter and intra document dependencies. Regulatory and standards authorities have long recognised the importance of reliable SCM mechanisms, especially in the development of high integrity software systems [3, 8, 9]. An important supporting technology for SCM is version control, which concerns storage and retrieval of different versions of development components. Most version control systems attempt to maintain a record of the changes ( deltas ) between different versions of components. This provides the ....

U.K. Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment. Defence Standard 00-55, August 1995. http://www.dstan.mod.uk/ or http://www.seasys.demon.co.uk/.

.... but highly costly activity in many domains; especially those in which products are subject to regulation or certification (e.g. safety critical systems) While the use of formal methods in supplying such evidence is often recommended or mandated (e.g. SEMSPLC guidelines [13] MOD guidelines [32]) their practical application remains undeniably di#cult. This is largely because most formal methods rely on intimate knowledge and explicit manipulation of some underlying, generic model and are typically less concerned with user oriented representations. Thus, given a system expressed as ....

UK Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment. MOD Interim Standard 00-55, 1993.

.... of formal methods generally may be found in [45, 46, 47] Besides OSI communication standards as a realm of application, other standards which have, or are using advocating formal methods, include many for safety [20] e.g. aviation [29] safety critical systems [26, 27] space [28] defence [22, 23], railways [21] and nuclear power station software [24] Formal methods have also been applied in attempts to understand graphics standards, e.g. the Graphical Kernel System (ISO 7942) the Programmers Hierarchical Interactive Graphics Standard (ISO 9592) Computer Graphics Metafile (ISO 8632) ....

Ministry of Defence. The Procurement of Safety-Critical Software in Defence Equipment. (Part 1: Requirements, Part 2: Guidance). Interim Defence Standard 00-55, Issue 1, Ministry of Defence, Directorate of Standardization, Kentigern House, 65 Brown Street, Glasgow, G2 8EX, UK, April 1991.

....perceived) cost of formal methods, the benefits of catching errors early can easily outweigh the cost of applying formal methods [4, 5] For safety critical or quality critical applications, the cost of formality may be only a minor factor. Indeed, for certain types of application (e.g. in defence [6, 7]) the use of formal methods may be mandatory. Unfortunately, formal specification of requirements suffers from two major problems: the incomprehensibility of a formal specification to a typical client (or developer ) and the need to balance the rigour of a formal method against the inherently ....

Ministry of Defence. The procurement of safety-critical software in defence equipment --- Part 2: Guidance. Technical Report Defence Standard 00-55, Issue 1, Ministry of Defence, Glasgow, UK, April 1991.

....perceived) cost of formal methods, the benefits of catching errors early can easily outweigh the cost of applying formal methods [4, 5] For safety critical or quality critical applications, the cost of formality may be only a minor factor. Indeed, for certain types of application (e.g. in defence [6, 7]) the use of formal methods may be mandatory. Unfortunately, formal specification of requirements suffers from two major problems: the incomprehensibility of a formal specification to a typical client (or developer ) and the need to balance the rigour of a formal method against the inherently ....

Ministry of Defence. The procurement of safety-critical software in defence equipment --- Part 1: Requirements. Technical Report Defence Standard 00-55, Issue 1, Ministry of Defence, Glasgow, UK, April 1991.

....in specifying parts of its CICS transaction processing system [3, 10] Z has been used to clarify an IEEE floating point standard [1] there is work being done towards a Z standard [14] and formal methods including Z are recommended by the U.K. Ministry of Defence for certain classes of project [15]. However, although Z provides a good method for specifying software systems, it stumbles slightly when it comes time to develop the specification into a corresponding implementation. This is by no means a fatal flaw, since formal specification can be very valuable in its own right, but if we hope ....

U.K. Ministry of Defence, The procurement of safety critical software in defence equipment. Interim Defence Standard 00-55, Issue 1, April 1991.

....will increase the need of being able to specify exactly what a system does, and furthermore, to prove it (at least som parts of it) In some governmental areas today, FM must be used in order to be allowed to deliver the product. One example is the British Interim Defence Standard 00 55[Min91a, Min91b] As for PLCs, many qualified Swedish judgers, e.g. Statens Provningsanstalt (SP) and Statens Karnkraftsinspektion (SKI) have the opinion that the industry during the 1990s should replace hardware systems with programmable software systems. This will clearly result in a metagenesis of how ....

Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment (part2 -- guidance), April 1991.

....This will increase the need of being able to specify exactly what a system does, and furthermore, to prove it (at least som parts of it) In some governmental areas today, FM must be used in order to be allowed to deliver the product. One example is the British Interim Defence Standard 00 55[Min91a, Min91b] As for PLCs, many qualified Swedish judgers, e.g. Statens Provningsanstalt (SP) and Statens Karnkraftsinspektion (SKI) have the opinion that the industry during the 1990s should replace hardware systems with programmable software systems. This will clearly result in a metagenesis of ....

Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment (part1 -- requirements), April 1991.

....during system refinement. 1 Introduction The need for formal methods in the development of safety critical software systems is now well accepted. Current standards for the development of such systems (e.g. Australian Department of Defence, 1998; International Electrotechnical Commission, 1995; U.K. Ministry of Defence, 1995] mandate the use of formal methods for high levels of safety assurance. Most safety critical systems are embedded systems which can cause harm (i.e. loss of life or injury) by failure to correctly interact with their environment. Since such failures are often of a time related nature, ....

U.K. Ministry of Defence (1995). The Procurement of Safety Critical Software in Defence Equipment. Defence Standard 00-55.

....conditions, which might otherwise go unnoticed. As a result there are requirements for software analysis in the MOD standard for Presented at 1999ACMSIGPLAN WorkshoponProgram Analysis for Software Tools and Engineering, Toulouse, France, September 1999. safety critical software DEF STAN 00 55 [MOD91] and also in the avionics standard DO178B [RTC92] Software analysis is very widely used in industry, not only for safety critical systems, but also as an aid to the production of high quality software. There are also a wide range of hazard analysis approach which are applied to software ....

Ministry of Defence, Directorate of Standardisation, Kentigern House, 65 Brown Street, Glasgow G2 8EX. Interim Defence Standard 00-55. The procurement of safety critical software in Defence equipment, April 1991.

No context found.

UK Ministry of Defence. The Procurement of Safety Critical Software in Defence Equipment, 1991. Interim Defence Standard 00-55/Issue 1.

No context found.

Ministry of Defence Directorate of Standardisation. Defence Standard No. 0055 (Part 2)/2 --- The Procurement of Safety Critical Software in Defence Equipment Part 2: Guidance, August 1995.

No context found.

U. K. Ministry of Defence. The procurement of safety critical software in defence equipment. Interim Defence Standard 00-55, MOD Directorate of Standardization, Kentigern House, 65 Brown Street, Glasgow G2 8EX, UK, 1991.

No context found.

U. K. Ministry of Defence. The procurement of safety critical software in defence equipment. Interim Defence Standard 00-55, MOD Directorate of Standardization, Kentigern House, 65 Brown Street, Glasgow G2 8EX, UK, 1991.

No context found.

Ministry of Defence, The Procurement of Safety Critical Software in Defence Equipment, DEF-STAN 00-55, Issue 1, Part 2. Room 5150, Kentigern House, 65 Brown St., Glasgow G2 8EX, 1997.

No context found.

U.K. Ministry of Defence, The Procurement of Safety Critical Software in Defence Equipment, INTERIM Defence Standard 00-55 (PART 1: REQUIREMENTS)/Issue 1, 5 April 1991.

No context found.

Ministry of Defence, The Procurement of Safety Critical Software in Defence Equipment, Draft Interim DEF-STAN 00-55, Room 5150, Kentigern House, 65 Brown St., Glasgow G2 8EX, 1995.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC