Results From Generic Model

A key source of issues for the robustness of distributed automotive systems is from low voltage transients such as when cranking the engine with a battery in a low state of charge. In such situations at critical voltages the operational states of different parts of a distributed system may change highly dynamically and in a non-uniform fashion across the system giving the potential for operational issues. Novel approaches to developing practical tests on physical systems have been developed (Huang et al, 2010) but it would be desirable to use simulation to test such conditions, leading to early detection and resolution of issues. Hence a simulation of a low voltage crank was used to test the modelled system, examples of the results are shown in Figure 5.10.

Figure 5.10: Simulation of low voltage cranking on generic model

Powermode 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 t(S) Supply Voltage 0 2 4 6 8 10 12 14 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 t(S) ECU Status -1 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ECU Status 1 ECU Status 2 ECU Status 3 ECU Status 4 ECU Status 5

Function Status

0 0.5 1

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Function_Status_A Function_Status_B Function_Status_C Function_Status_D

Cranking Engine Running Accessory On Initialising Shut Down Slee p Unpowered Forced shut-down On Of f I Max (A) 0 2 4 6 8 10 12 14 16 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 t(S)

In the test scenario shown in Figure 5.10 the engine start switch was pressed and held triggering a 3 second engine crank and then pressed again after 10 seconds to shut off engine, entering accessory mode for 4 seconds before going into power-off mode shutting down all ECUs as shown on the powermode graph. The supply voltage graph in Figure 5.10 shows a typical sinusoidal voltage dip when the engine is cranking, which recovers after the engine fires. It is possible to vary this signal pseudo-randomly to test a variety of scenarios.

The ECU status graph shows the resultant operational state of the ECUs illustrated by an integer value (0 = unpowered, 1= Sleep, 2 = Shutdown, 3 = Initialising, 4 = Running). A value of -1 is used where an ECU has gone unpowered without going through full shutdown which can cause anomalous behaviour. In the test scenario the crank signal has provoked this state in one of the ECUs. The ECUs can be seen to have varying times for initialization and shutdown. One ECU does not initialize until around 8 seconds the effect of this in delaying operation of functions can be seen in the functional status graph.

The graph marked I Max in Figure 5.10 shows the combined maximum current draw of the ECUs. This figure is of interest in maintaining voltage stability and in the detection of quiescent current issues, caused for example by nodes not going to sleep and keeping other nodes on the network awake.

While the results for this scenario with a limited number of interacting nodes and functions are readily understandable, as the complexity increases to that of real systems, they become less intuitive. The next step has been to apply the modelling principles shown to a specific application.

5.4.4 MOST Control Channel Model – Initialisation Robustness Issues

The specific application targeted was the initialisation of an infotainment system based on a MOST (Media Oriented System Transport) fibre optic network. The objective of this

modelling was to be able to simulate the initialisation process to be able to understand the critical parameters to the robustness and consistency of the process and to be able to investigate enhanced alternative strategies.

Analysis of MOST initialisations has shown a number of interesting behaviours. During high initialisation bus loading, cases have been observed where multiple slave modules are sending control messages to the master module simultaneously, leading to a high number of Non-Acknowledged messages (NAKS) which must be re-sent. During this period of intense retries it was possible for one slave module to monopolise the master module where only its messages were being received and acknowledged. This prompted the following questions to be investigated through the modelling. Why is the network services cycle time, the rate at which the network services software task is called by the module's operating system, the same in all nodes and could varying them improve initialisation timing? Why is the low level retry number, the number of times the Network Interface Controller will attempt to re-send a message, set to the same value in all nodes and could varying them improve initialisation timing? Why is the low level retry timing identical in all nodes and could varying them improve initialisation timing? During the notification setting phase, all modules are trying to set notifications simultaneously. This causes high MOST control channel bus loading, therefore high numbers of not-acknowledged messages, leading to initialisation delays.

Measures of network performance during start-up include: the time from light on until the system is fully initialised with all notifications set and audio sources set up, the time from light on until a particular customer feature is available and the number of MOST message low level and high level retries used.

Adjustable parameters which affect initialisation performance include: the Network Services cycle time, the number of low level retries and their timing, the use of application

buffering strategy, the MOST ring order, the scheduling of notification setting, and therefore order of feature availability. These parameters are not fixed in the MOST specifications and are therefore need to be specified by the vehicle manufacturer or module suppliers. Some of these parameters such as number and timing of low level retries have remained constant since the very first MOST system designs, and have been re-used on subsequent systems. For parameters such as the network services cycle time, only simple guidance might be given to the module suppliers, such as the master node should be faster than the slave nodes. Optimising these parameters could be achieved by practical experimentation. Clearly this could become a long and expensive process, as it would require support from several module suppliers to produce special prototype software and hardware.

The application of the model is to examine the network initialisation strategy and predict the effects of changing parameters, e.g. retry wait times, over a wide variety of initialisation scenarios. A specific question of interest to the technical specialist was; although forbidden by the MOST standard, could varying the low level retry spacing across the network improve performance in a system where only the master node is able to send broadcast messages, and group cast messages are not used?

The objectives are to determine and specify requirements for the MOST system to guarantee predictable initialisation behaviour, and understand the effects of increasing customer feature on the MOST system in advance of building prototypes.