Towards a Formalism-Based Toolkit for Automotive Applications

The success of a number of projects has been shown to be significantly improved by the use of a formalism. However, there remains an open issue: to what extent can a development process based on a singular formal notation and method succeed. The majority of approaches demonstrate a low level of flexibility by attempting to use a single notation to express all of the different aspects encountered in software development. Often, these approaches leave a number of scalability issues open. We prefer a more eclectic approach. In our experience, the use of a formalism-based toolkit with adequate notations for each development phase is a viable solution. Following this principle, any specific notation is used only where and when it is really suitable and not necessarily over the entire software lifecycle. The approach explored in this article is perhaps slowly emerging in practice - we hope to accelerate its adoption. However, the major challenge is still finding the best way to instantiate it for each specific application scenario. In this work, we describe a development process and method for automotive applications which consists of five phases. The process recognizes the need for having adequate (and tailored) notations (Problem Frames, Requirements State Machine Language, and Event-B) for each development phase as well as direct traceability between the documents produced during each phase. This allows for a stepwise verification/validation of the system under development. The ideas for the formal development method have evolved over two significant case studies carried out in the DEPLOY project

Control dependence for extended finite state machines

Though there has been nearly three decades of work on program slicing, there has been comparatively little work on slicing for state machines. One of the primary challenges that currently presents a barrier to wider application of state machine slicing is the problem of determining control dependence. We survey existing related definitions, introducing a new definition that subsumes one and extends another. We illustrate that by using this new definition our slices respect Weiser slicing’s termination behaviour. We prove results that clarify the relationships between our definition and older ones, following this up with examples to motivate the need for these differences

Requirements specification and architecture design for internet-based control

The Internet is playing an important role not only in information retrieving, but also in industrial processes manipulation. This paper describes an approach to writing requirements specification for Internet-based control systems and to deriving architecture for this new type of control systems according to the requirements specification. Specification is described in terms of a functional model and then extended into information architecture. Distinct from the functional model, the information architecture gives an indication to the architecture of the Internet-based control systems. An integrated-distributed architecture has been derived from the functional model and the information architecture as a case study

Data Processing for IoT in Oil and Gas Refineries

This paper summarizes and gives examples of the using of IoT in Industry 4.0, especially in Oil and Gas Refineries. Industry 4.0 and Industrial Internet of Things (IIoT) technologies are driving digitalization driven by software and data solutions in many areas, particularly in industrial automation and manufacturing systems. Global refineries are currently all heavily instrumented, and process regulated in real-time to the millisecond. To meet the ever-increasing needs of operational demands, SCADA, Distributed Control Systems and Programmable Logic Controllers (DCS & PLCs) have grown significantly. On the other hand, certain assets and operations in a refinery are still not being monitored or evaluated in real-time. If an error occurs that causes production to be hampered, the company must bear large losses even though production stops in just a matter of minutes. This is one of the reasons why the oil and gas sector is starting to implement the Internet of Things (IoT). The overall aim of this paper is to give and summarize several papers to provide solutions for a simple process monitoring system that would enable process operators to identify any sources of abnormality quickly and easily in the process. A system is being made so that it can be accessed and transmit data remotely via a computer network and will display conditions in real-time without being limited by distance, space, and time. This will allow all previously disconnected assets and processes to be linked and monitored in real-time in a simpler, cost-effective, and easy-to-implement manner

Dynamic Certification for Autonomous Systems

Autonomous systems are often deployed in complex sociotechnical environments, such as public roads, where they must behave safely and securely. Unlike many traditionally engineered systems, autonomous systems are expected to behave predictably in varying "open world" environmental contexts that cannot be fully specified formally. As a result, assurance about autonomous systems requires us to develop new certification methods and mathematical tools that can bound the uncertainty engendered by these diverse deployment scenarios, rather than relying on static tools

An approach to verification and validation of a reliable multicasting protocol: Extended Abstract

This paper describes the process of implementing a complex communications protocol that provides reliable delivery of data in multicast-capable, packet-switching telecommunication networks. The protocol, called the Reliable Multicasting Protocol (RMP), was developed incrementally using a combination of formal and informal techniques in an attempt to ensure the correctness of its implementation. Our development process involved three concurrent activities: (1) the initial construction and incremental enhancement of a formal state model of the protocol machine; (2) the initial coding and incremental enhancement of the implementation; and (3) model-based testing of iterative implementations of the protocol. These activities were carried out by two separate teams: a design team and a V&V team. The design team built the first version of RMP with limited functionality to handle only nominal requirements of data delivery. This initial version did not handle off-nominal cases such as network partitions or site failures. Meanwhile, the V&V team concurrently developed a formal model of the requirements using a variant of SCR-based state tables. Based on these requirements tables, the V&V team developed test cases to exercise the implementation. In a series of iterative steps, the design team added new functionality to the implementation while the V&V team kept the state model in fidelity with the implementation. This was done by generating test cases based on suspected errant or off-nominal behaviors predicted by the current model. If the execution of a test in the model and implementation agreed, then the test either found a potential problem or verified a required behavior. However, if the execution of a test was different in the model and implementation, then the differences helped identify inconsistencies between the model and implementation. In either case, the dialogue between both teams drove the co-evolution of the model and implementation. We have found that this interactive, iterative approach to development allows software designers to focus on delivery of nominal functionality while the V&V team can focus on analysis of off nominal cases. Testing serves as the vehicle for keeping the model and implementation in fidelity with each other. This paper describes (1) our experiences in developing our process model; and (2) three example problems found during the development of RMP. Although RMP has provided our research effort with a rich set of test cases, it also has practical applications within NASA. For example, RMP is being considered for use in the NASA EOSDIS project due to its significant performance benefits in applications that need to replicate large amounts of data to many network sites

METHODS OF CHECKING AND USING SAFETY CRITERIA

This article describes methods and tools for automated safety analysis of UML statechart specifications. The general safety criteria described in the literature are reviewed, updated and applied for using in automated specification completeness and consistency analysis of object-oriented specifications. These techniques are proposed and based on OCL expressions, graph transformations and reachability analysis. To help the checking intermediate representations will be introduced. For using these forms, the correctness and completeness of checker methods can be proven. For the non-checkable criteria two constructive methods are proposed. They use design patterns and OCL expressions to enforce observation of the safety criteria. The usability and the rules of using will be also discussed. Three real systems have been checked by using these methods

An Approach to Verification and Validation of a Reliable Multicasting Protocol

This paper describes the process of implementing a complex communications protocol that provides reliable delivery of data in multicast-capable, packet-switching telecommunication networks. The protocol, called the Reliable Multicasting Protocol (RMP), was developed incrementally using a combination of formal and informal techniques in an attempt to ensure the correctness of its implementation. Our development process involved three concurrent activities: (1) the initial construction and incremental enhancement of a formal state model of the protocol machine; (2) the initial coding and incremental enhancement of the implementation; and (3) model-based testing of iterative implementations of the protocol. These activities were carried out by two separate teams: a design team and a V&V team. The design team built the first version of RMP with limited functionality to handle only nominal requirements of data delivery. In a series of iterative steps, the design team added new functionality to the implementation while the V&V team kept the state model in fidelity with the implementation. This was done by generating test cases based on suspected errant or offnominal behaviors predicted by the current model. If the execution of a test was different between the model and implementation, then the differences helped identify inconsistencies between the model and implementation. The dialogue between both teams drove the co-evolution of the model and implementation. Testing served as the vehicle for keeping the model and implementation in fidelity with each other. This paper describes (1) our experiences in developing our process model; and (2) three example problems found during the development of RMP