David Harel and Amir Pnueli [1] confidently asserted that "A natural, comprehensive, and understandable description of the behavioural aspects of a system is a must in all stages of the system’s development cycle, and, for that matter, after it is completed too." Even this confident assertion is an understatement. System behaviour is more than a must in CPS development: it is the very heart and focus of the system, and the essential product of its development.
Developing dependable system behaviour is difficult. The essence of the task is programming the bipartite system—the quasi-formal machine, and the decidedly non-formal physical world. Making a unified program for this heterogeneous combination is hard. It cannot be achieved by separating the two parts at a formal specification interface, because neither part can be understood without the other.
System behaviour is where the software engineers meet the stakeholders. What is the only thing the machine in a system can do? It can govern behaviour in the world. What can ensure satisfaction of the most important stakeholder requirements? The governed behaviour.
Success in software engineering for a system is success in behaviour development. Desired and dependable governed behaviour is the crucial criterion of success. An occurrence of undesired and unexpected behaviour is an instance of system failure.
Where is the chief complexity in a cyber-physical system? In the physical world interactions of the constituent behaviours that make up the whole system behaviour.
Why must software engineers develop formal models of the non-formal physical world? Because those models must guide and justify the design of the machine's software that will evoke the system behaviour.
Developing system behaviour is a prime application of the principle of incremental complication. The elementary components from which the system behaviour is constructed are triplets. A triplet is a simple machine with its governed world, and the behaviour they evoke. Triplets that can execute concurrently must be reconciled to eliminate mutual conflict, sometimes being modified from their initial simple form. In a further design stage the control of concurrency is introduced to manage contingencies such as the need for pre-emptive termination of a behaviour.
[1] David Harel and Amir Pnueli; On the development of reactive systems; in K R Apt ed, Logics and models of concurrent systems, pages 477-498; Springer-Verlag New York, 1985.
Links to other posts:
↑ Cyber-Physical Systems: The essential character of a cyber-physical system
↓ System Behaviour Complexity: The component structure of system behaviour
→ Triplets: Triplets are system behaviour elements: (Machine+World=Behaviour)
No comments:
Post a Comment