System Engineering Phases

The process starts with a problem $\cal{P}$ of a stakeholder. Through a communication process, the systems engineer tries to understand the stakeholders vision, desires, and needs and tries to translate his understanding of $P$ into a behavior model $\cal{M_{S-R}}$^2.1 that represents the complete expected behavior of the system to be designed:

$$requirementsAnalysis: \cal{P} \longrightarrow \cal{M_{S-R}}$$

Figure 2.2: Representational Modes of the Behavior Model

As shown in fig.2.2 three main modes of representation can be distinguished: (1) A written text in normal (everyday) language. This is assumed as the default mode. (2) A pictorial mode using pictures, diagrams, figures as 'language' to represent the intended domain (the 'meaning') of interest. (3) A formal model which is capable to be processed by automatic verification processes.

The logic behind this distinction is based on epistemology and semiotics. From semiotics (three of the founders of semiotics are Charles S. Peirce, Ferdinand de Saussure, and Charles Morris) we can learn, that a sign needs at least the element of a sign vehicle, something different which is intended as the object and a meaning relation which is built up in an interpreter (the 'semiotic agent'). While sign vehicle and object can be empirical objects it holds that the meaning relation is fundamentally non-empirical ('subjective'). Therefore in every communication between different semiotic agents they have to assure a sufficient similarity of their used meaning relations. The inevitable difference between the meaning relations of different semiotic agents (like stakeholder and engineers) is often called the 'semantic gap' (cf. Doeben-Henisch/ Wagner (2007)[34]).

From epistemology (citations have to inserted....) we can learn, that our brain is taking the different sensor signals from the outside and the inside of the body constructs an internal world model which is nearly three-dimensional filled up with object like entities. Between these objects there exist implicitly a bunch of relations. Furthermore is the model continuously updated and changing of properties of this internal world model are becoming 'visible'. This fundamental space-object-relation-change structure (also called 'ontological structure' or the 'meaning dimension' or the 'semantics') is directly reflected in every known human language (citations have to inserted....).

If the engineers are translating their understanding of the stakeholder's world model into plain text then are the different meaning relations of the stakeholder not explicitly visible. Openly perceivable are only the sign vehicles used, but these can be interpreted very differently. Therefore are plain texts written in an everyday language a constant source of misunderstandings. One possible strategy to overcome this special weakness of the everyday language is the usage of those pictorial languages which represent the semantic space 'inside' the interpreters explicitly. Examples of such pictorial languages are e.g. the diagrams of the SysML language (cf. SysML OMG-2007 [149]). An overview of the main SysML-diagrams is given in figure 2.3:

Figure 2.3: Modeling of the HMI Domain

Especially used during this course are:

1. Use case diagrams can be related to the task set $\Gamma$, which the user has to complete. Therefore is the use case diagram always a good starting point for modeling the intended behavior (cf. SysML 2012 [109],chapter 14).

2. State diagrams can model each interface as a state machine on it's own, but one can also combine three state machines -each for each type of interface- and subsume these three as substates under a general state machine HMI-environment (cf. SysML 2012 [109],chapter 13).

3. Interaction/Sequence diagrams are helpful to characterize the sequence of interactions between all participating surfaces by using timely and logical order (cf. SysML 2012 [109],chapter 12).

4. Requirements diagrams can be used to specify a bit more precise the inner structure of a task by subsuming special actions. With regard to the necessary verification and validation of these requirements on can enhance all requirements with test cases.

Although such diagrams (additionally supported by textual comments) can be helpful to minimize misunderstanding these diagrams are usually not fitting well if here is a need for (automatic) formal verification. In that case one needs a formal representation which can be processed by formal mechanisms (logical derivations) or -in the case of automatic processes- or by a computer. In the latter case one uses either automatic proof procedures or model based strategies based on the language of automata (cf. Doeben-Henisch (2009)[35]).

A direct connection between the diagram language of SysML and the language of automata can be found by using the state machine diagram of SysML. This can be understood as a graph representing the structure of an automaton. This leads immediately to a formal representation.

Part of the behavior model will be a sufficient definition of the intended system interface (SI) which is needed to realize the necessary actions of the user.

Based on $\cal{M_{S-R}}$, the systems engineer develops a system model -also called functional specification- $\cal{M_{SYS}}$ that fullfills the condition $\cal{M_{S-R}} \Longleftrightarrow \cal{M_{SYS}}$:

$$synthesis: \cal{M_{S-R}} \longrightarrow \cal{M_{SYS}}$$

The $\cal{M_{SYS}}$ is converted into a real system $\cal{M_{SYS*}}$:

$$implementation: \cal{M_{SYS}} \longrightarrow \cal{M_{SYS*}}$$

Validation is realized as a measurement process:

$$validation: \cal{M_{S-R}} \times \cal{M_{SYS*}} \longmapsto \cal{V}$$

where $\cal{V}$ is a set of validation values indicating the correlation between the behavior model $\cal{M_{S-R}}$ and the system model $\cal{M_{SYS}}$.

The process to convert $\cal{P}$ (in the non-symbolic space) into formalized requirements $\cal{M_{S-R}}$ (in the symbolic space) and the symbolic system model $\cal{M_{SYS}}$ into the real system $\cal{M_{SYS*}}$ cannot be fully automated, because full automation is restricted to the symbolic space. The challenge of relating symbolic and non-symbolic spaces with each other also occurs during validation, when non-symbolic objects are compared with a symbolic description [].

The general structure of the behavior model $\cal{M_{S-R}}$ can be described as a sequence of combined states $\langle z_{0}, ..., z_{f}\rangle$. A combined state $z$ is defined by the driving task set $\Gamma$, the participating surfaces of the user called user interface (UI), the intended system interface (SI), and the assumed environment interface (EI), thus, $z_{i} \in Z \subseteq \Gamma \times INTF_{U} \times INTF_{S} \times INTF_{E}$. A state change from a state $z_{i}$ to a state $z_{i+1}$ is caused by an action $\alpha_{i} \in ACT \subseteq Z \times Z$. Every sequence $p$ of states for which it holds that $(z_{i}, z_{i+1}) \in \alpha_{i}$ is called a usage process or short behavior of the behavior model. The complete set of all possible behaviors of $\cal{M_{S-R}}$ is described by the generating function $\delta$ that maps a start state $z_{0}$ into the possible usage processes ending in the final states or goal states. A complete behavior model $\cal{M_{S-R}}$ can then be defined as

$$M_{S-R} = \langle \Gamma, INTERF_{E/U/S}, Z, ACT, \delta, S, G_{F}\rangle$$

where $G_{F} \subseteq Z$ is a set of goal states which shall be reached starting with the beginning state $S$.

The constraints induced by the systems engineering process challenge the systems engineer to specify the required properties of a system in terms of its observable behavior, including the interactions with the users and the environment. A nontrivial aspect of this modeling is the interpretation of the task set $\Gamma$ at least by the user $U$. This presupposes that a single task $\tau_{i} \in \Gamma$ is given as some string written in some language $L_{\Gamma}$ which can be interpreted by the user $U$. Usually is this interpretation not part of the behavior model. But with regard to training and testing of users it could be necessary to include a complete specification of the language $L_{\Gamma}$ as well as their intended interpretation $\cal{I}$ by the user. The semantic of the langugae $L_{\Gamma}$ has as its domain of reference the complete behavior model $\cal{M_{S-R}}$. Besides this it has to be noticed, that in the case of intelligent systems one has to assume that the behavior labeled 'intelligent' $\cal{M_{I}}$ is a subset of the general behavior, thus $\cal{M_{I}} \subseteq \cal{M_{S-R}}$