Generic Methodology for Robustness Modelling

In this section the approach to robustness modelling developed within this chapter is explained as a generic methodology with wider applicability. The approach focuses on modelling the availability of resources required for service delivery, in particular processing and communication, rather than modelling the specific functionality of the service. This model should be ideally created as soon as the initial deployment architecture for the service under consideration is available. This deployment architecture should define the Electronic Control Units (ECUs) involved in the service delivery, the interaction between them and the communication networks. For robustness considerations it is essential to understand which ECUs are providers of inputs to the ECU controlling the service delivery.

Figure 5.37 illustrates the generic structure of the robustness model. The ECU controlling the service delivery and ECUs which are providers of inputs are modelled as interlinked state machines. The ECUs have inputs associated with timing, user inputs, system operating mode and power supply which the case studies showed were all critical parameters in robustness related issues. There is also a block within the model concerned with distributed functions based on availability of processing and communication resources. Each block is described in more detail in the subsequent paragraphs.

Figure 5.37 Generic structure of Robustness Model

The timing block provides a common clock signal to the ECU blocks and should be set to a higher level of resolution than expected response times within the system. For the initial development this was set to 1 ms and for the infotainment study reduced to 1 µs. This is then used by each individual ECU block as a shared definition of time and to ensure their state machines can respond sufficiently quickly noting there will be need to model the response of events within a statemachine to occur more slowly to reflect actual system responses.

User inputs which affect both the specific service under consideration and also the wider system operating mode should be modelled. Typically these are modelled as switches between binary values or constant blocks giving parametric values. For a vehicle system the operating mode (powermode) is typically influenced by wake up events such as door unlocks, door opening and pressing of start button.

Using these inputs the System Operating Mode determines the current operating mode of the vehicle (Powermode) and then sends this to the ECUs which will each take appropriate initialisation or shut-down responses.

The power supply voltage level was found to be a critical parameter in the case studies particularly with respect to short low voltage fluctuations during starting of the engine. The power supply block provides a parameter-based, continuous analogue signal of the voltage level to the ECUs and can simulate voltage fluctuations when the powermode indicates an engine starting state.

Figure 5.38 illustrates the inputs and outputs to a generic ECU Block. The timing input is used to trigger the state machine and to determine the duration of events. The supply voltage input is used to determine whether the ECU is powered or unpowered depending on its minimum operating voltage parameter. The System Operating Mode input is used to determine whether the ECU should power up or shut down. Significant parameters of the ECU which can impact availability and are subject to variation should be set by constant blocks which user can configure. Typically this should include: minimum operating voltage, initialisation time, shutdown time, cycle times for performing specific tasks e.g. servicing communication interfaces and any built in delays within the system to wait for external events to occur. The external reset causes the ECU to re-initialise to be able to fault inject to simulate the effect of internal ECU faults such as watchdog resets. The external wake-up causes the ECU to initialise to facilitate fault injection of spurious ECU wake-ups. Comms In is used for other input signals needed for the ECU platform to initialise and shut-down. The Comms Out is the data which the ECU provides to other ECUs required for the delivery of the required service. Where possible the actual messages should be abstracted into generic classes represented by an enumerated value of the message types. The node status is used to

availability in terms of ability to function and communicate. In a model it is also possible to make observable parameters which in an actual system would not be, such as ECU initialisation states or buffer utilisation in the case of the MOST infotainment model.

The Comms Out and the Node Status information are used by the distributed system block to determine the availability of the particular service under consideration. The block can also be used to implement distributed functions for arbitrating communications to determine which of the messages that the ECUs attempt to send will be successful.

Figure 5.38 Generic ECU block inputs and outputs

Figure 5.39 shows the internal structure of a generic ECU block illustrating the generic states and transitions between them. If the voltage is below the minimum operating voltage the ECU will be in the Unpowered state. When voltage is above minimum operating voltage then the ECU will go into either asleep or initialisation state depending on inputs such as system operating mode. In the sleep state the ECU uses minimum power until it receives a wake-up trigger to initialise. The initialisation state represents the time delay for boot-up of microprocessors and communication devices which is an externally configurable parameter.

After this is complete an ECU is considered to be in its running state and able to execute communication functions and application layer interactions which may be necessary before the service can be provided. Some ECUs have shutdown routines, e.g. data-storage, that they must perform before going to sleep mode. Power interruption during shut-down can cause issues e.g. failure to write-back to non-dynamic memory, which should be captured in the model by a different Node Status value.

Figure 5.39 Generic ECU block internal structure

The level of detail of the modelling of the application layer interface interactions and communications layer will vary depending on the characteristics of the specific system as was seen in the generic model and the MOST initialisation models.

The testing of the model should be determined by the requirements coming from the Robustness Case. This will be explored further through application of the methods in combination in the next chapter.

Chapter 6 - Development of New Robustness Techniques