This paper describes the lessons we learned over a thirteen year period while helping to develop the shutdown systems for the nuclear generating station at Darlington, Ontario, Canada. We begin with a brief description of the project and then show how we modified processes and notations developed in the academic community so that they are acceptable for use in industry. We highlight some of the topics that proved to be particularly challenging and that would benefit from more in-depth study without the pressure of project deadlines.

Abstract. Many safety-critical software applications are hard real-time systems. They have stringent timing requirements that have to be met. We present a description of timing behaviour that includes precise definitions as well as analysis of how functional timing requirements interact with performance timing requirements, and how these concepts can be used by software designers. The definitions and analysis presented explicitly deal with tolerances in all timing durations. Preliminary work indicates that some requirements may be met at significantly reduced CPU bandwidth through reduced variation in cycle time.

The amount and impact of software-dependence in critical systems impinging on daily life is increasing rapidly. In many of these systems, inadequate software and systems engineering can lead to economic disaster, injuries or death. Society generally does not recognize the potential of losses from deficiencies of systems due to software until after some mishap occurs. Then there is an outcry, reflecting societal expectations; however, few know what it takes to achieve the expected safety and, in general, loss-prevention.On the one hand there are unprecedented, exponential increases in size, inter-dependencies, intricacies, numbers and variety in the systems and distribution of development processes across organizations and cultures. On the other hand, industry's capability to verify and validate these systems has not kept up. Mere compliance with existing standards, techniques, and regulations cannot guarantee the safety properties of these systems. The gap between practice and capability is increasing rapidly.This paper considers the future of software engineering as needed to support development and certification of safety-critical softwaredependent systems. We identify a collection of challenges and document their current state, the desired state, gaps and barriers to reaching the desired state, and potential directions in software engineering research and education that could address the gaps and barriers.

No abstract

Abstract. Safety cases have become popular, even mandated, in a number of jurisdictions that develop products that have to be safe. Prior to their use in software certification, safety cases were already in use in domains like aviation, military applications, and the nuclear industry. Argument based methodologies/approaches have recently become the cornerstone for structuring justification and evidence to support safety claims. We believe that the safety case methodology is useful for the software certification domain, but needs to be tailored, more clearly defined, and more appropriately structured in analogy with regulatory regimes in classical engineering disciplines. This paper presents a number of reasons as to why current approaches to safety cases do not satisfy essential attributes for an effective software certification process and proposes improvements based on lessons learned from other engineering disciplines. In particular, the safety case approach lacks the highly prescriptive and domain specific nature that can be seen in other engineering specialities, in terms of engineering and analysis methods to be applied in generating the relevant evidence. Safety case approaches and corresponding methods should aim to achieve the levels of precision and effectiveness of engineering methods underpinning regulatory regimes in other engineering disciplines.

No abstract

Abstract. Many industrial control systems use programmable logic controllers (PLCs) since they provide a highly reliable, off-the-shelf hardware platform. On the programming side, function blocks (FBs) are reusable components provided by the PLC supplier that can be combined to implement the required system behaviour. A higher quality system may be realized if the FBs are pre-certified to be compliant with an international standard such as IEC 61131-3. We present an approach to formalizing FB requirements using tabular expressions, and to verifying the correctness of the FBs implementations in the PVS proof environment. We applied our approach to the example FBs of IEC 61131-3 and identified issues in the standard: ambiguous behavioural descriptions, missing assumptions, and erroneous implementations.

No abstract