Design, process safety software

Many process safety information databases are designed to share metrics across a facility or even an entire enterprise. For example, databases developed to monitor PHA studies across an enterprise can track PHA studies by business, by site, and by unit. Systems are developed by the operating company or purchased from a systems vendor, and some enterprise business software can provide similar capabilities. 

The concept of a highly automated scale-up process is enticing. One vision of such a process for homogeneous (liquid phase, non-catalytic) reactions starts with little more than a list of reactants, solvents, and desired products. Given this information as well as constraints imposed by economic, environmental, safety, and practical factors, a highly automated system could include both software and hardware components to generate an optimal reactor design. The necessary software components would ... 

The safety characteristics of the SP1NL1NE3 solution and the stringent and proven safety software development process applied by the Nuclear department of the Schneider Electric company have made acceptable the principle of a design based on redundant identical processing units for this project. In addition, because of the possible consequences in case of the NIS not performing its protection fonction on demand, the licensing authority has required an FMEA oriented toward the SCCF risk as part of the safety case. 

Brazendale, J. and Lloyd, I., 1989. The design and validation of software used in control systems — safety implications. Hazards X Process Safety in Fine and... 

Section 3.6 Synthesis. Includes the approach and methods to transform the fimctional architecmre into a design architecture (hardware, software, and humans to support the system life cycle), to define alternative system concepts, to define physical interfaces, and to select preferred product and process solutions. Describes how requirements are eonverted into detailed design specifications for hardware, software, human engineering, manpower, personnel, safety, training, and interfaces. Approaches and methods for the engineering areas, quahty factors, and engineering specialty areas in Section 3.2 are also defined. In addition, nondevelopmental items and parts control are included. 

The mass- and energy-based indicators help to identify process alternatives for which sustainability metrics, environmental impact factors, as well as inherent safety indices can be estimated. The goal here is to optimize the process so that there is improvement in all these metrics with respect to the base case design. The application of the methodology requires a combination of tools ranging from databases to process simulation software (such as Aspen , Hypro , Sim Sci , etc.), to computational routines for various types of indicators and process synthesis/design tools. 

ANSI/ISA-84.01-1996 requires that the application software be developed in accordance with the Safety Requirements Specification (SRS). ANSI/ISA-84.00.01-2004-1 also requires this, but discusses the development of the application software with relation to the safety lifecycle. Where hardware is prone to random failures, the software is more prone to systematic failures. The safety lifecycle is important, because it is the primary mechanism for reducing systematic failure. The inclusion of the lifecycle discussion in the software section does result in repetition of the design process described in ANSI/ISA-84.00.01-2004-1 Clause 11. This repetition is intended to highlight the importance of the lifecycle in the development, verification and validation of application software. ISA-TR84.00.04-1 Annex O provides a discussion of the evolution of application software development. 

To be able to certify that software can be commercialized because it is safe and fulfils its mission for public health, an inspector needs to know what the software does, that it works properly and that it does not imply risks. Validation of safety is a broad concept for medical devices in software speak it means the assurance that the process of software design, construction and verification is planned and controlled. 

Prior to modification, analysis of impact on safety of process and software design... 

Aerospace has continued to provide many engineering, design, and safety services to the Air Force for more than 40 years. One of its chief functions is to perform launch verification and readiness assessments for all Air Force space launches. Aerospace s launch verification procedure is veiy broad, beginning with analysis of launch system design. Aerospace independently tests physical components and software, checks manufacturing processes, and verifies correct assembly of the launch vehicle. Finally, Aerospace delivers a formal launch verification letter to the Air Force s Space and Missile Systems Center, monitors the launch, and analyzes launch and post-launch data (Tomei, 2003). All of the functions are redundant in the sense that Air Force and contractor personnel also perform most of the same functions. Aerospace s launch verification serves as an independent, objective assessment of launch safety that the Air Force uses in conjunction with its own analyses in making launch decisions. 

The guidance is applicable to systems important to safety as defined in Refs [2, 3]. Since at present the reliability of a computer based system cannot be predicted on the sole basis of, or built in by, the design process, it is difficult to define and to agree systematically on aity possible relaxation in the guidance to apply to software for safety related systems. Whenever possible, recommendations which apply only to safety systems and not to safety related systems are explicitly identified. 

The SAR is an important safety product because it provides an overview of the system level of risk at that point in time. It can show where the system has been effectively designed for safety and it can also point out where more safety focus is needed. Development of the SAR is an iterative process during the life of the program and should be prepared for each major program milestone to assist in program decision making. Total system risk will be underestimated if anything is omitted from the assessment, such as hazards, software, COTS items, or human factors. 

The concept of contract is not uncommon in software development and it was first introduced in 1988 by Meyer [12] to constrain the interactions that occur between objects. Contract-based design [3] is defined as an approach where the design process is seen as a successive assembly of components where a component behaviour is represented in terms of assumptions about its environment and guarantees about its behavior. Hence, contracts are intended to describe functional and behavioral properties for each design component in form of assumptions and guarantees. In this paper, a contract which describes properties that are only safety-related is referred to as a safety contract. 

In addition to the aforementioned benefits the model based design process also provides the opportunity of automatically generating production code for the target platform when following the formal workflow as part of the overall IEC61508 software safety lifecycle. As stated by the certification entity TUV SUD,... 

---