1. Rigorous Development Of a Safety-Critical System Based on Coordinated Atomic ActionsBy
Subash M S

2. The Idea
To design and build a fault-tolerant control Program for a realistically-detailed model of an industrial production Cell using Coordinated atomic (CA) actions.
Then Debug, improve and verify the design formally.
2/29
Subash M S

3. Organization and sections
Description of CA, Fault-Tolerant Production cell model
Analysis of possible failures of devices and sensors of Production cell
Control program that using CA actions both for structuring and exception handling.
Formal treatment of CA action-based designs and formalize properties of Production Cell II
Discuss an implementation of the control program
Conclusion
3/29
Subash M S

4. CA Actions and Production CELL II
Definition of CA Actions: It is a mechanism for coordinating multi-threaded interactions and ensuring consistent access to objects in the presence of concurrency and potential faults.
4/29
Subash M S

5. Overview and Example of a CA Action
CA action consists of roles executing in parallel performing operations on objects
Upon the occurrence of an error appropriate forward/reverse recovery must be performed cooperatively by all roles to reach a mutually consistent conclusion
A recovery line must be provided by the CA action in order to coordinate the recovery of roles without domino effect
5/29
Subash M S

6. Overview and Example of a CA Action Contd…
An Acceptance test is provided to determine whether the outcome of the CA action is successful
External objects which are shared between various CA actions must provide their own error coordination mechanisms
These external objects must also behave atomically with respect each CA action in order to prevent information smuggling
6/29
Subash M S

7. Overview and Example of a CA Action Contd…
7/29
Subash M S

8. Overview and Example of a CA Action Contd…
The desired effect of the CA action becomes visible to the entire system only if the acceptance test is passed.
The acceptance test allows both a normal and one or more exceptional outcomes to be visible
Each exceptional outcome signals a specified exception to the environment.
If the Acceptance test is not passed the erroneous visible out come is undone and an Abort exception is signaled to the environment.
If the error cannot be undone and it is visible, a Failure exception is signaled to the environment so that it may deal with the situation.
8/29
Subash M S

9. The fault tolerant production cell
9/29
Subash M S

10. Basic system requirements of the control program
Safety
Liveness
Failure detection and continuous service
10/29
Subash M S

11. Failure Definitions and Analysis
Assumptions:
The system clock, traffic lights and alarm signal are fault-free and do not fail
Values of sensors, actuators and clocks are always transmitted correctly without any error
No failure can cause any device to exceed limiting positions
All sensor failures are indicated by sensor values
All actuator failures will cause devices to stop
11/29
Subash M S

12. Possible types of failure
Failure Definitions and Analysis Contd…
Possible types of failure
Sensor Failures
Actuator Failures
Lost Blank
All of the above mentioned failures can be detected by monitoring various sensor values corresponding to the different Devices, Robot, Press…etc and using assertion statements to check for the failure.
However This is not that simple, because though detection of a failure is easy, Distinguishing and deciding which type of exception or failure has occurred is very difficult. This is why in most cases, the cell has to be stopped to identify the failure and correct it.
12/29
Subash M S

13. Control Program based on CA Actions for Production Cell II
There are six concurrent execution threads
Feed belt
Table
Robot
Press1
Press2
Deposit belt
Additional Threads are
Blank supplier
Blank consumer
13/29
Subash M S

14. Control Program based on CA Actions for Production Cell II Contd…
14/29
Subash M S

15. Control Program based on CA Actions for Production Cell II Contd…
Intersection between CA Actions represents the fact that they cannot be executed in parallel
Each hardware device is associated with a device-controller (a thread) which is responsible for dynamically the sequence of actions that the device will participate in
Action will begin only if its pre-conditions are valid, and its post conditions will hold if no exception is raised during the execution of the action.
15/29
Subash M S

16. CA Action example: Load Press I
16/29
Subash M S

17. Description of the CA Action using the COALA notation
CAA LoadPress1;
Interface
Use
MetalBlank;
Roles
Robot: blankType, robotActuator;
Press1: blankType, press1Actuator;
RobotSensor: arm1ExtensionSensor, robotAngleSensor;
Press1Sensor: blankSensor, lowPositionSensor, midPositionSensor;
Exceptions
Press1Failure, Arm1Failure1, ...; ;;exceptions to signal
Body
Use CAA ;;specify nested actions
RotateRobot, MovePress1toMiddle, ExtendArm1, RetractArm1;
Object
robotPress1Channel: Channel; ;;shared local objects
17/29
Subash M S

18. Description of the CA Action using the COALA notation Contd…
Exceptions
press1_failure, blank_sensor_failure, ...; ;;internal exceptions
Handlers
press1_handler, blank_sensor_handler, ...;
Resolution
press1_failure -> press1_handler, ...; ;;exception resolution graph
Role Robot(...);
Role Press1(...);
...
End LoadPress1;
18/29
Subash M S

19. Dealing with component Failures
failure of a component involved in the CA action is detected by using assertion statement
Exception is raised by one or more roles and is propagated to other roles
Control is transferred to exception handlers to perform appropriate error recovery
In most cases it is not possible to completely recover to normal Post conditions
19/29
Subash M S

20. Handler examples and exceptional post-conditions
Handler for Press1:
The Load press1 action performs forward error recovery and tries to move the blank to press2 which is still operational
Handler for the Rotary Sensor or motor Failure:
In this case Backward error recovery is used and the robot is moved back to its initial position and attempt is made to rotate it again
20/29
Subash M S

21. Exceptional outcomes:
Incase the handlers are not able to eliminate the failure it leads to one of the following exceptional outcomes and corresponding one or more post-condition
21/29
Subash M S

22. Dealing with Concurrent Failures
22/29
Subash M S

23. Design of Device-Controllers
Device/Sensor-controllers are used to determine dynamically the order in which the CA actions are executed.
For Production Cell II model:
Feedbelt, Table, Robot, Press1, Press2, DepositBelt, Supplier, Consumer
Two queue objects are defined :
RobotQueue and depositbeltQueue
23/29
Subash M S

24. Device-Controller Example: Press1
PressController:
loop forever {
robotQueue.put(PRESS1_FREE)
LoadPress1.Press(Plate)
ForgeBlank.Press(Plate)
robotQueue.put(FORGED_PLATE_IN_PRESS1)
UnloadPress1.Press(Plate) }
24/29
Subash M S

25. Interactions between controllers and CA Actions
25/29
Subash M S

26. An Implementation The Fault-Tolerant Production Cell Simulator 26/29
Subash M S

27. Features of Production Cell Simulator
Outlines of 12 top-level CA actions are displayed on the simulator
Outlines are gradually colored in gradually during system execution to show CA action execution dynamically
Dynamic process if exception handling will be shown using color change within outline
Up to two Failures can be injected into the Production Cell simulator dynamically
During testing all injected device or Sensor failures were caught successfully and handled immediately by the control program. Even a previously unknown software bug in the original simulator was detected by the acceptance test of a CA action and recovered by the retry operation of the Ca action.
27/29
Subash M S

28. An Implementation Contd…
Failure Injection Panel
28/29
Subash M S

29. Conclusion
This work represents the first and complete formal analysis for the complex and realistic Production Cell II
Analysis has been conducted on the possible component failures and ways to identify these failures.
Results of the analysis has been used to guide the design of the system employing a very sophisticated exception handling scheme, capable of dealing appropriately even with concurrent occurrences of any of the wide variety of possible failures defined in the FZI specification of Production Cell II
Different Design, focusing mainly on cooperation between devices during both normal execution and during exception handling
Design style used was one that has been reached through very specific consideration of the problems raised by the production Cell examples
29/29
Subash M S