MOST Control Channel Model Implementation

The requirement for the model was to have representative levels of MOST control channel traffic in terms of source, destination and relative timing of messages during the initialisation phase and representative behaviour of the channel for factors such as timing, bandwidth and arbitration.

Based on the generic model previously described, the MOST system was modelled as a series of interlinked state machines. The model was constructed using Matlab Simulink and Stateflow, a top level view is shown in Figure 5.11. The model of a 9 node system was constructed using an existing system as a reference for the communication patterns and MOST specifications to determine underlying behaviours.

Figure 5.11- Top level view of MOST initialisation model

Figure 5.12 illustrates the top level inputs and outputs of a node. These are similar to the generic models with the following MOST specific additions. The node position and number of nodes allows the ring configuration to be changed. The MOST Bus input is a signal bus from the arbitration node providing: which node has won arbitration transmitted message, the content of the transmitted message, whether messages have been acknowledged, and whether the ring is complete. The MOST Bus output is a signal bus to the arbitration node containing: message transmit requests, content and priority, received message acknowledgement and a binary signal to indicate when the node’s transmitting light output is on. The node status output gives an enumerated value corresponding to its stage of initialisation. The node also outputs its current number of low level retries and the number of

Figure 5.12- Enlarged view of node

Further inputs which were previously identified as impacting initialisation timing and set as user definable parameters within each node are; the minimum operating voltage, the ECU initialisation time, the network interface wakeup time from detecting light at its input, low-level retry interval, the number of low-level retries, the high level retry interval and number, the netservices cycle time, the number of vehicle status requests the node makes during initialisation and the buffer size of the application message handler.

Figure 5.13 shows the high level structure of a node which has similar structure to the generic model with states for unpowered, sleep, initialising and running. States have been added for ring restart to capture behaviour during loss of light around the fibre optic ring, either during shut-down or a fault, and the initialisation has been split into the initialisation of the micro-processor and of the network interface. The major change is in the running state where the key part of the modelling was to determine which aspects of the control channel communications to abstract and how to model them. An approach of only modelling at particular layers in the OSI Reference Model was not possible as the behaviour is a factor of

all layers, so the model included layers used in MOST. These are known as the application layer, application message handler layer, netservices layer and network interface controller and were modelled with appropriate abstractions at each layer which will subsequently be described.

Figure 5.13 - Overall structure of a node in the model

Application Layer

The application layer controls the high level behaviours and implements the initialisation strategy. The top layer of the application layer block is shown in Figure 5.14 illustrating the key stages of the initialisation process which reflects the specified

waits for the network to become active and then the master sets a timer to allow all participants to join before checking which functions are present on the individual nodes. On receiving a valid configuration the master broadcasts a configuration status OK message which triggers the individual nodes to request via a “Central Registry Get” message either for for the full central registry of functions and their location or a portion relating to functions of interest. At this point the slave nodes also request the vehicle configuration from the master and on completion of this the master broadcasts a message to the nodes to commence set-up. This consists of the nodes requesting notification of the status of other functions and is complete on receipt of responses at which time normal running can take place.

Figure 5.14 Application layer initialisation states in master node

The major abstractions in the application layer were in abstracting the messages into generic classes and simplifying the interaction at application level to generic types or patterns

where the message sent dictated particular response behaviour by the receiver. The actual data was not required merely just enough information to trigger representative message traffic in terms of timing, number, priority, source and destination of messages. Table 5.2 shows part of the message abstraction table which gives the enumerated value of the message types.

Value of Message_Contents

Variable Corresponding MOST Message Comments

0 No message Default value when no message is transmitted 1 - 14 Reserved Allows plotting on same graph as Tx/Rx Nodes

15 FBlockIDs.Get 16 FBlockIDs.Status

17 FBlockIDs.Status Segmented message not last message 18 FBlockIDs.Status Segmented message last message 19

20

21 Configuration.Status.ConfigurationControl Ok Sent when valid central registry built 22 Configuration.Status.ConfigurationControl Changed

23 Configuration.Status.ConfigurationControl Not Ok 24 CentralRegistry.Get

25 CentralRegistry.Get All 26 CentralRegistry.Status

27 CentralRegistry.Status Segmented message not last message

28 CentralRegistry.Status Segmented message last message 29

30 Vehicle Status Request (Fblock 0xF5 ) not last request ECU Confirmation stage - Each ECU requests vehicle config status from Master & checks (some nodes may have mutiple requests) 31 Vehicle Status Request (Fblock 0xF5 ) last request ECU Confirmation stage - Each ECU requests

vehicle config status from Master & checks (some nodes may have mutiple requests) 32 Vehicle Status Response (Fblock 0xF5 ) ECU Confirmation stage - Response from Master

for Vehicle status

Table 5.2 MOST modelling message abstraction table

Generic patterns of interactions during initialisation were observed from specifications and analysis of traces. Two examples of such patterns are shown. Figure 5.15 shows the state machine for behaviours in a slave node during check system configuration phase of initialisation. The node waits for an incoming message type corresponding to an “Fblock request” from the master for it to declare its functions. In response the node creates a new “Fblock Status” request and calls the message handler layer to transmit it. The System check

Figure 5.15 Slave node application layer behaviour during check system configuration

Figure 5.16 shows the state machine for behaviour in a slave node during notification set-up phase of initialisation. The node sends a series of notification requests to appropriate nodes using the message handler. The set of notification requests and appropriate responses for each node was derived through analysis of actual system behaviour. These were categorised into different types based on the response from the receiving node. One simplification used in the model was to create globally accessible variables for the location of the nodes in the ring to determine the location nodes should set notification on. This facilitated the abstraction of data from the messaging while maintaining fidelity of message traffic. Notification setting has a high level retry strategy triggered by a message send failure at lower level whereby it will attempt to resend after an interval, typically 500ms.

Figure 5.16 Slave node application layer behaviour during notification phase of initialisation

Message Handler Layer

The message handler layer interfaces between application and netservices layers. Figure 5.17 shows the top level structure of this model block illustrating the main functions, which are performed in parallel. The outgoing message handler takes send requests from the application level and queues them in priority for the netservices layer. Similarly the incoming message handler takes incoming messages from the netservices and queues them to be responded to. The other functions deal with routine responses and consumption of messages which are not part of the node’s own initialisation. Receive FBlock status consumes the FBlock status messages from nodes where notification has been set. The notification handler

based on the type of notification request. The Receive vehicle status function consumes vehicle status messages, other than being received they have no other impact on the initialisation behaviour. Receive new message processing acknowledgement is a response to particular types of notification requests where the status information requested is not immediately available and the response is to generate a periodic message confirming the response is still being processed.

Figure 5.17 Message handler layer functions

Netservices Layer

The Netservices layer is shown in Figure 5.18. The Call Netservices block periodically executes the netservices register interface according at an interval defined by a user settable parameter. The netservices register interface receives the next message in the network interface controller’s incoming message register and loads the next outgoing message to its

outgoing message register and reads the message send result register, reporting back if the previous message has been successfully sent or failed to send.

Figure 5.18 NetServices layer functions

Network Interface Controller Layer

The top level functions in the network interface controller layer are shown in Figure 5.19. The message transmission function takes an outgoing message, assigns a priority to it according to the message type and the number of times it has failed to win in the arbitration process and sends this to the central arbitration block which is discussed subsequently, via the outgoing message signal bus. If the message is sent but failed to be received it implements the low-level retry strategy according to the set parameters. If still the message fails it records message send failure. The message reception function detects if the node is the destination for a transmitted message on the incoming message signal bus. If the received

register still has a message then it set a message not acknowledged (NAK) flag. The values of these flags are sent to the arbitration block via the output signal bus. The final functions relate to the light input and output of the optical physical layer which is abstracted to a Boolean value on the message input and output busses. When the Set_Node_No_Light_On

function detects the value of the output from the previous node changing from Off to On it sets the value of the lightoutput for its node to On. When the Monitor_Light_ In function detects the ring on value from the arbitration node it enables message receipt, if the value changes to ring_off it causes a state change from running to ring-restart.

Figure 5.19 Network interface controller block in nodes

A major simplification for the model which reduced the implementation effort while retaining the same communication behaviour, was to model the message arbitration as a centralised process whereas in practise it is a distributed process. Figure 5.20 shows the top

level of the arbitration block which takes the bus access requests from all nodes, determines which has the highest priority, makes the associated message content the content of the transmitted message on the block’s output and sets a flag to indicate to the nodes that there is a new message. The arbitration block also sends a message to indicate the arbitration winning block and the result of whether the message is acknowledged or not acknowledged by recipient nodes. A further function is to confirm whether full ring is running by monitoring the light-output of all nodes and output this to the nodes to confirm communication is possible.

Figure 5.20 MOST Control Channel arbitration block

node against enumerated stages, the number of low level and high-level retries, the number of not acknowledged messages (NAKs) and the utilization of the internal buffer in the nodes.