A model is a representation of a subject: it represents the subject by acting as a surrogate for some purposes. Intentionally, it abstracts from the subject by representing only selected aspects, chosen according to the model’s purpose. Models may take several forms. A photograph, painting or sculpture may be an iconic model of a person. A text may be a linguistic model, perhaps in a natural language. If the language is artificial and fully formal the text is a symbolic model. Sometimes one part of physical reality may be used as an analogic model of another—when, for example, the flow of current in an electrical circuit is modelled by the flow of water in a system of pipes, or the operations of a business system or a robot are represented in objects of the system’s programming language. A model may use mixed forms: a map, for example, may be partly iconic and partly linguistic.
Only symbolic models allow the reliable formal reasoning essential to developing critical cyber-physical systems. A symbolic model is both rigorously separated from its subject and intimately associated with it. Separated because the model’s symbolic expressions directly denote nothing except elements of the formal calculus: only correct use of the calculus matters. Intimately associated because an explicit interpretation maps model expressions and observable realities in the subject. Bypassing the interpretation by using subject names as model terms—a common practice when programming language objects are used as analogic models—blurs the fundamental dichotomy of model and subject.
A model whose subject does not yet exist may be a specification model, stating properties which the subject must possess. A model describing an existing subject is an assertion model, making factual claims which may prove false. In both cases the relationship is mediated by the interpretation.
A model is made for a purpose, and its statements must serve that purpose. For a cyber-physical system, dependable behaviour design is the overarching purpose: when failure occurs, diagnosis and explanation are rightly demanded from the model. Physical behaviour is effectuated, above all, by physical causal links: to diagnose and explain wrong behaviour one must know what right behaviour would have been—and why. Models explicitly representing causal links are therefore necessary both to forestall failure in design and to explain it in hindsight.
Like traditional software design, cyber-physical modelling must be practised both in-the-small and in-the large. Modelling-in-the-small chiefly concerns models for triplets; modelling-in-the-large chiefly concerns elaborating triplets into realistic constituent behaviours and combining them into the complete system behaviour.