A direct comparison is made of the methodology, defined in chapter 6, against its five aims, outlined in section 5.2. A more general assessment, follows, addressing the problem and solution domains, as indicated in section 4.2.
Creating DCS requirements from the manufacturing requirements is achieved. FMCs make concurrently operating machine tools and work handling equipment to co-operate, and this is accomplished via
Strategy 2 concurrent and sequential actions and set out in Petri net graphs via Strategy 3 structuralise and modularise in task 1 of step 1. Manufacturing operations such as load lathe and start lathe are issued by level 2 workstation controllers. Using Strategy 1 output work backwards as described in section 5.3.6, then the DCS is created from the needs of the outputs.
Goal 2 comprehensibility applied to Petri net graphs and manifest in Strategy 2 concurrent and sequential actions and Strategy 3 structuralise and modularise satisfies the second aim. It is much easier to
understand the overall Petri net graph than the labyrinth Petri net graph.
Goal 1 Petri net/occam equivalence is achieved by restricting outputOR Petri net communication between controllers via Strategy 1 output work backwards. Following the simple tasks of step 4 enables code to be translated from the Petri net graphs. The methodology exploits the formalisms of Petri nets and occam, but their mathematical bases do not have to be understood in order to use the methodology. However, the methodology, the Petri net firing task and the occam language must be understood. This non-reliance on mathematical comprehension should be attractive to industry.
Strategy 4 deadlock avoidance is implemented in task 1 of step 1 by imposing a cell controller and status handler controller aided by Strategy 1 output work backwards. Strategy 1 output work backwards, implemented in tasks 4 to 7 of step 2, achieves a uni-directional flow of information. The update between the cell controller and status handler is governed by the cell controller, and it is this controlled update that prevents deadlock by 'circular wait', described in section 4.10.1, while enabling closed loop control. Occam code that compiles, executes what is wanted without deadlock and terminates, is correct, refer to section 3.2.2. The code produced, via use of the methodology does what is anted and terminates, thus fulfils the validity and verification requirements of section 3.2.2.1.
Problem and Solution Domains
The motivation for the methodology has perhaps imposed restrictions on its applicability, i.e. its problem domain, and on the target hardware and software, i.e. its solution domain.
The initial motivation was to transputerise an FMC, and the subsequent analysis highlighted the manufacturing requirements (refer to section 2.7) for safe, reliable and correct distributed control. This pre-determines much of the solution domain, by negating the selection of hardware, but leaving open the choice and development of software. The safety and distributed requirements bear heavily on the methodology, and lead to a restriction in the problem domain, which is for dependable distributed control.
The Problem Domain: Dependable Distributed Control
The safety requirement determines the use of formally based modelling, design and analysis of hardware and software components to ensure correctness. It also determines the use of reliable hardware, and possible hardware and software redundancy. The distributed requirement, originally done by an office LAN, requires correct and reliable message transmission between the nodes controlling the machine tools
and work handling. The control requirement, originally accomplished by running Pascal code on IBM compatible PCs, requires correct and reliable execution of manufacturing control software.
The Solution Domain
The solution domain is pre-empted by the imposition to use transputers. However, transputers and their programming language, occam, satisfy the distribution and control requirements by their mathematical bases, and by the transputer's on-chip communication, processing and memory and its high quality manufacture.
A significant design choice was to exploit this underlying formalism, and to introduce another mathematically base tool to assist in the design process. Petri nets were chosen for their capability of modelling, analysing and designing concurrent systems in matrix and graphical forms. The Petri net specification of the FMC was produced, refer to the ‘labyrinth’ Petri net graph, but it is unreadable. This incomprehensibility indicates that it is not enough to adopt correct design and implementation tools (Petri net and occam) and use reliable hardware (transputers) to achieve dependability, but there is a need to understand the design and communicate it.
It is technically possible to analyse the Petri net specification of the FMC manually and by Petri net analysis tools. However, the absence of the latter and the unreadability restricting the former, rendered the Petri net graph almost useless.
Similarities between the structures of Petri nets and occam were noticed, and an equivalence was sought. Petri nets allow the inputAND, output AND, inputOR and outputOR of Figure 3-13, while occam does not permit the non-deterministic outputOR. An equivalence is achieved by preventing the designer from building non-deterministic outputORs. This leads to Goal 1 Petri net/occam equivalence.
Petri net analysis can show that the design contains faults, but does not show how to correct them. Another significant design choice was to avoid faults, rather than to eliminate or tolerate them, to achieve deadlock freedom and hence correctness. Of the four manifestations of deadlock, avoiding, or
controlling, 'circular wait' was chosen. This lead to the predominant uni-directional flow of information, with a controlled update, to create a single and deterministic closed loop cycle. This lead to Goal 3 pro activity and Strategy 4 deadlock avoidance.