7.2.1 Abstract Protocols
How can application-level abstractions be made accessible during analysis and how can they be used in describing communication scenarios? The key idea is the introduction of a separate application-specific protocol layer. A relationship between two layers can be established by relating messages on one layer with messages on an adjacent layer. For example, from the viewpoint of the request/reply protocol notification messages do not exist, they are introduced on the protocol layer above. The term abstract protocol will be used to refer to such application-specific protocols. The right-hand side of the sequence chart in Figure 7.2 shows how communication is perceived when analysing the notifica- tion layer. It is important to understand, that abstract protocols also introduce the idea of abstract communication channels. That is, the messages shown are independent of the actual physical media on which lower-level messages are sent. An abstract message may actually be implemented through a set of different messages in different sub-networks.
To support abstract protocols, an analyser must be aware of the additional service level introduced by an application. For the notification-example, this means that a notification protocol is defined where valid communication consists only of a server sending a noti- fication message to a client. The protocol is then related to the request/reply protocol by defining how a pattern on the request/reply layer maps to a message on the notification layer: a request message from a client followed by a positive reply from the server to the same client should be interpreted as a notification message from server to client. The notification protocol captures the design intention of the application designer. Abstract protocols may be stacked in the same way as regular protocols. An abstract protocol can be stacked on top of another abstract protocol. Indeed, even the request/reply protocol of the example just discussed may be an abstract protocol based on a yet lower protocol layer. This approach is open ended and can be used to build levels of abstraction in a stepwise fashion, thereby mirroring the abstraction process in the application itself.
7.2.2 Complex Scenarios
A complex scenario is a chain of communication events, possibly in different subsystems, that can be associated with a use case. An example of a use case is a braking manoeuvre in a car with adaptive brake lights. If the user – a driver in this case – performs a braking ma- noeuvre that activates ABS (Anti-lock Braking System), the brake light potentially shows some reaction that deviates from its normal behaviour, depending on speed, strength of braking and the reaction of the driving assistance systems. The use case can be described as: The driver performs a hard braking manoeuvre. At the level of ECUs, the following – simplified – scenario can be derived from the use case:
1. The braking system registers blocking of tires and activates the anti-lock brakes. 2. The braking system notifies other components listening on the bus of the anti-lock
brake activity.
3. The control unit in charge of the adaptive brake light registers the activity of the ABS and requests the current speed vc of the car from the instrument cluster. 4. Because vc is higher than the threshold vt, the control unit decides to instruct the
brake light system to flash.
A second scenario associated with the same use case shares the first three steps, only that in step 4 it determines vc vtand thus does not interfere with the normal operation of the brake light. While the above natural-language description of scenarios is rather im- precise, scenarios can be precisely described at the level of the actual messages exchanged between components over the communication buses.
Complex scenarios pose a challenge for both specification and testing of ECUs. They may involve a large number of different messages in different subsystems. In addition to that, the resulting communication patterns are likely to be interrupted as vehicle com- munications systems are heavily impacted by stochastic triggers arising from the system environment [119]. For example, mobile phone calls may appear at any time as well as warnings and recommendations from driver information and assistance systems. Even for moderate scenarios, the amount of communication to process may rise to an extent that makes monitoring and verification of scenarios a complex task. Describing the scenarios at the right level of abstraction is crucial for reducing complexity.
7.3 Defining Layers with CFR Models
Abstract protocols can provide a high level of abstraction to specify communication sce- narios as patterns on abstract application-specific message sequences rather than on highly interleaved implementation-specific message sequences. The process of creating an ab- stract protocol can be described in three steps. Firstly, filtering out all messages not per- taining to the protocol implementation. Secondly, describing rules that relate patterns in the remaining messages to the abstract protocol layer. Thirdly, joining the resulting mes- sages from different sources on a new channel.
7.3.1 Channels, Filters and Rules
As explained in the context of the request/reply example, it is a common technique to stack protocol layers in such a way that each layer interfaces directly adjacent protocol layers only. In this way, a protocol layer Lnis described by relating its communication patterns to the communication patterns on the next lower layer Ln 1. Indeed, that is how the abstract notification protocol is informally described: a request for notification message from a client followed by a positive reply from the server to the same client should be rendered on the next higher layer as a notification message from server to client. Examining this natural language description of the protocol layer reveals that the following information is provided:
• Certain messages on the lower protocol layer are identified. • The sequence in which these messages occur is given.
• A mapping of this message sequence to a message on the higher-level protocol layer is defined.
The follwing conceptual framework for defining protocol layers is the foundation of the language formalised and defined in the next sections. It defines three core concepts:
• A channel is a medium that transports a sequence of messages over time. The mes- sages obey a concrete or abstract protocol. A protocol defines the message format and optionally a set of legal communication patterns.
• A filter is a passive and stateless message processing unit that redirects messages from a channel to a positive or negative output channel based on a filter criterion. The scope of a filter is a single message.
• A rule is an active and stateful message processing unit that consumes messages from one or more inputs and emits messages to at least one output. In opposition to filters, a rule may modify or create messages.
7.3.2 Models, Abstraction and Interpretation
CFR models relate protocol layers by composing channels, filters and rules. The inputs and outputs of filters and rules are sequences of messages. Theoretically, this allows arbi- trary interconnection. Nevertheless, for methodological reasons, it is forbidden to directly connect filters with rules and vice versa. This constraint has the goal of producing more readable and reusable models by separating the concepts. The restriction does not reduce the expressive power of CFR models because placing an otherwise unconnected channel between a filter and a rule is equivalent to connecting the two elements directly. Inputs and outputs are abstracted by input and output pins. An input pin may be connected to an output pin using a connector. Channels and rules have an arbitrary number of input and output pins while filters have exactly one input and two output pins.
CFR models contain an abstraction mechanism for filters and rules. Compound filters can be defined by connecting existing filters. Rules can be defined by arbitrary CFR mod- els with defined inputs and outputs. This abstraction mechanism allows to define rules and filters based on a set of primitive filters and to reuse compound filters as if they were primitive. Filters and rules that cannot be defined by composition are described using an external language. The requirement for the filter language is to express criteria on a message-level and the requirement for the rule language is to express criteria on the se- quence level.
CFR models can be interpreted in two similar but distinct ways: (1) as a specification that defines a higher protocol layer through a lower protocol layer or (2) as instructions for a protocol analyser on how to render communication on a higher layer by observing communication on a lower layer.
Figure 7.3 shows the basic principle of using filters and rules for relating a protocol on a channel (Ch) to a protocol on an adjacent channel. The primary interest when analysing systems is the “bottom-up’ mapping. The goal is to find communication patterns and make them visible. In principle, a mapping could be defined “top-down” so that abstract protocol messages can be related to messages on the lower layer. This could for instance be used for describing a message generator on a high level of abstraction. If filters and rules are reversible, a mapping in one direction can be derived from a mapping in the other direction.
Figure 7.3: Relating Abstract Protocol Layers
7.3.3 Example: A CFR Model for the Notification Protocol
Let Crr be a channel over which messages defined by a protocol rr – the request/reply protocol – are sent. These messages include request and reply messages related to notifi- cations but also other request and reply messages not related to notifications. Let Cnotbe a channel over which notifications messages are sent. A CFR model that describes how the message stream on Crr can be transformed into a message stream on Cnot is defined by the following setup: The output pin of channel Crr is connected to the input pin of a Filter Fnot. The positive output pin of Fnot is connected to a channel Crrf. Fnot is config- ured in such a way that it sends all request/reply messages concerned with notifications to its positive output and all other messages to its negative output. Accordingly, the com- munication on Crrf consists only of the request/replies concerned with notifications and no other messages. The output pin of Crrf is connected to the input pin of rule Rnot. The first output pin of the rule is connected to the input pin of Cnot. The rule is configured in the following way: When a requests message from a client occurs, the rule memorises the request. When a positive reply that fits a previously memorised request is received, a no- tification message is sent through the output pin onto Cnot. The messages on Cnotare now notification messages sent from servers to clients. Omitting the filter and rule logic for the moment, the CFR model can be described as follows, whereby the ! means connected to and where Rnot(out1)denotes the first output channel of Rnot.
F ilter : Fnot Rule : Rnot
Crr(out) ! Fnot(in) Fnot(positive)! Crrf(in) Crrf(out)! Rnot(in) Rnot(out, 1) ! Cnot(in)
The example indicates that the restriction on combining filters and rules enforces reusable and clear designs. Channel Crrf is introduced as a helper because the output pin of Fnot must not be directly connected to the input pin of Rnot. The channel Crrf defines an intermediate step in the abstraction process. It introduces a sub-protocol on a layer that is between the request/reply and notification layers. This layer can be used for monitoring the flow of all messages pertaining to the notification protocol or re-used in further protocol or scenario definitions.