• First fully capable model-based design process - includes Executable Specification, Architecture and Optimization
  • Concurrent verification cuts 70% of the verification effort required by the V proces
  • Promotes safety, quality, reliability and economy throughout the supply chain 
  • The modelling and simulation of mobile (agent-based) systems is fully supported
Home > Technology > un-V: The EST Systems Engineering Process > A Traversal of EST’s Un-V Systems Engineering Process

A Traversal of EST’s Un-V Systems Engineering Process

The un-V process is a methodology with a number of steps:

  1. Requirements →
  2. Executable Specification + plant-control separation ↑→
  3. Architecture Control Space Generation & Reduction || Verification ↑→
  4. Control Optimization || Verification ↑→
  5. Realization – map data structures, map communications paths, map computation || Verification ↑→
  6. Generate physical system and proximal physical model of system || Verification ↑→
  7. Validation – demonstration that the physical system meets its goals as set in the Requirements ↑

For the above steps, there exists the normal feed-forward path (→) showing a progression through the 7 steps of the process.
There is also a potential, largely manual feedback path (↑) which might go from the current step to any of the previous steps, including the Requirements (the 1st step), because of a verification failure.
The further through the process that a product progresses the more remote that more than a single step back will be required to resolve a verification failure.

EST’s un-V Model-driven Systems Engineering process and the ESSE Systems Engineering Workbench work seamlessly together.

Step 1 – Requirements: In a well-designed model-based, control centric engineering process, the Requirements will be sufficient to develop a well-defined (unambiguous), parameterized Executable Specification that is suitable to control some physical plant nominated in the Requirements.

Step 2 – Executable Specifications: The Executable Specification will be complete in function and timing, contain parameters designed to test future hypotheses, and be absent of realization technology constraints – such as software and hardware.   Executable specifications are models – perhaps mathematical or quasi-mathematical – that are recursive composites of hierarchically composed function sub-models and/or communicationally coupled sub-models of the control and plant described in the Requirements.

Physical plant models are typically continuous, at least, in the time domain, and specified as differential, integral or differential algebraic equations. Control specification may also be continuous and use the same notations as plant models or use discretized notations such as finite state machines (FSMs), UML, etc. Often, the executable specification of a subsystem – both plant and control - presents as a monolithic system of equations. There are a number of ways to separate the control from the plant equations determined by the movable boundary between the structures and functions chosen to be incorporated into the plant with the remainder becoming control. Such control-plant systems are known as cyber-physical systems.

Formally, a cyber-physical system may be defined as a system comprised of distributed physical plant that is regulated and coordinated by networks of real-time control sub-systems in order to achieve the intended objectives detailed in the Requirements of the system. Each control subsystem is typically realized physically as, or as a model of, an electronic control unit executing software connected by peripheral devices to actuators and sensors that effect, and measure the responses of, respectively, one or more pieces of plant. Cyber-physical systems can be stationary or mobile.
Examples of cyber-physical systems include vehicles (automotive, aerospace, nautical), robots, traffic control systems, industrial control systems, etc.

The definition may be extended to networked systems of cyber-physical systems. For such systems of systems to be interesting, they must be able to communicate.
Examples of cyber-physical systems of systems include communicating vehicles in traffic coordinated by traffic control, industrial automation systems coordinating multiple robots in a manufacturing line, a network of network routers, fixed and mobile telecommunications systems, army-navy-airforce vehicles involved in military training exercises or battle, etc.

Step 3 – Architectural Space: The parameters of the composed models that constitute a system enable the system’s architectural space of executable specifications to be generated, searched and optimizations found that match the desired objective functions detailed in the Requirements. The architectural space is often of high dimensionality where a dimension is associated with each parameter p[k] that may have a finite number v[k] of either quantitative or qualitative values, where k=1..s (s being the number of parameters). The dimensionality of the space is s and the number of points in the space is the product in s terms v[1] x v[2] x … x v[s].  Typical systems might have a few to thousands of parameters with each parameter being able to be assigned a number of values.

Step 4 - Optimization: The initial empirical investigation of the space is designed to reduce effectively the number of parameters, leaving only those that will have significant impact on the objective functions; and to reduce the number of values able to be assigned to each parameter to only those that will affect appreciably the output of the objective functions. For example, parameters that are highly correlated should be replaced by one representative parameter that has a limited number of values. Such objective functions define the optimization constraints that when collectively satisfied will achieve the original objectives specified in the Requirements. There is considerable literature on optimization strategies and techniques.

Concurrent verification: The Requirements will also contain as complete as possible verification scenarios and test cases relevant to the whole system. This enables the empirical verification of optimal Executable Specifications against their Requirements to ensure that the specifications meet their requirements.

Step 5 – Design: From this point on, the process steps into a physical, or proximal physical model, design that, typically, involves mappings of communication couplings to networks, computation to software and/or electronic hardware, and couplings between control and plant to interconnections between the electronic hardware and the physical plant. In modern, real-time engineering design and development processes, software and/or finite-state machines are often semi-automatically generated from the mathematical specification of the control in which the nexus between timing and function has been preserved or manually inserted.

The design process requires the concrete representation of data in a hardware or embedded software context that had an abstract representation at the executable specification level. Such contexts may be physical (electronics and/or software) or modelled as proximal physical (also called, operational) models. The concrete representation of numeric values as fixed or floating-point numbers with limited precision is of particular importance when the executable specifications are in the form of differential or integral equations. The numerical solving of such equations requires iterative integration and differentiation algorithms, where the bounding of numerical errors is required in order to compute reliable results. The limited precision of number representation is a major contributor to numerical errors. The physical representation of abstract data types – numerical and non-numerical - impacts computational complexity and bandwidth and latency requirements of both computation and communication in realized physical or modelled proximal physical systems.

Step 6 – Physical and proximal physical model realization: The generation, design or selection of hardware that meets timing constraints and realizes control as finite state machines or as the execution of software by electronic control units (ECU), and the signal translating connections between electronic hardware and plant, are the final steps in the realization of both a physical system and/or a proximal physical model of a system.  Both a physical and modelled ECU includes the processors, buses and peripheral devices required to execute the control software that controls the physical, or high fidelity model of, plant. In both the physical and proximal physical modelled environments, the ECU also executes the operating system and driver software that control the actions of the peripheral devices, such as sending and receiving the required signals and data to and from the plant, under the direction of the control software.

The realization steps are detailed and often complex and error prone, even so they are somewhat automatable – as the MathWorks and Vector have demonstrated. The mechanisms introduced during realization are in addition to the mechanisms introduced during the derivation of Executable Specifications from their Requirements. Every new representation accretes a set of mechanisms required to operate on it and a corresponding new set of scenarios and test cases to be added to the system’s verification suite. However, each set of accreted scenarios and test cases need only be known and used locally with its particular realization. And, the entire realized system must still be verified.

Steps 3-6 - Continuous verification: Once the Executable Specification together with  the verification scenarios and test cases of a system have been constructed, concurrently verifying each of the outputs from the Architecture, Optimization, and Design/Realization un-V process steps against its Executable Specification can be performed continuously. Variances are reported and the causes tracked down and fixed by the specification, architecture and design team.

Step 7 – Validation: Having realized a physical system it remains to demonstrate that it satisfies its Requirements. This is done by comparing as closely as possible, the responses from the physical systems and the responses from its equivalent Architecture (Executable Specification). There are some tests that cannot be applied to the physical system since it would result in death or serious injury. In the end, there is an engineering and corporate decision as to the acceptability of the validation and hence the safety of the system.

Continue on un-V: EST's Systems Engineering Process