CONTABLES SIGNIFICATIVAS

7.5.1 Specifying and Monitoring Complex Scenarios

Rules recognise a communication pattern on a protocol layer Li 1and abstract the pattern as a message on the next higher layer Li. By viewing scenarios as communication pat- terns, it becomes apparent that the approach for specifying protocol layers can be directly mapped to the specification of scenarios: a scenario is an abstract protocol with a single message. The messages of a scenario do not necessarily obey the same protocol. Com- plex scenarios such as those in the context of the brake light involve messages in different subnetworks. This makes specification using traditional techniques difficult. Abstract pro- tocols accommodate for the heterogeneity of the messages involved in a scenario: first all relevant messages are combined onto a single abstract protocol layer and based on this protocol layer the scenario layer is defined. To define this unifying protocol layer using CFR models, each combination of a bus and a protocol has to be defined as a channel. A configuration of filters selects the relevant messages from each channel and rules convert these messages into messages obeying the protocol of the unifying channel.

What is required is that each scenario is uniquely identifiable via its message se- quence. Ambiguities have to be resolved at the specification level. While there usually are a great number of protocol messages on the communication bus, the challenge is to identify only those messages that are relevant for a specific scenario. After these relevant messages have been singled out, they need to be assigned to a distinct scenario. This is the same procedure discussed for protocol abstraction. In this case, the low-level proto- col layer may be the message transport protocol, e.g., on a CAN bus, and the abstracted protocol layer is a scenario.

The application of CFR models for defining scenario analysers will be explained based on the two example scenarios introduced in Section 7.2.2 in the context of the adaptive brake light. Figure 7.4 shows the message sequence of the two scenarios. Both scenarios are associated with the use case of a strong brake manoeuvre by the driver. Sce- nario A describes this use case under high speed, where the brake light flashes. Scenario B describes the case where the speed is low and the brake light operates normally. The two scenarios are depicted as sequences of messages whereby both scenarios share a part of the message sequence. Message B1 marks the starting point for both scenario A and sce- nario B. Observing the message flow sequentially, starting at B1 there is an ambiguity for

SCENARIO A

SCENARIO B

blink light

SCENARIO A

SCENARIO B

blink light

speed high speed low

speed?

ABS

B1

Figure 7.4: Two Scenarios based on the Adaptive Brake Light Use Case

the first three messages. The communication pattern can unambiguously be assigned to scenarios A or B only after the message speed-high or speed-low can be identified. With each new message, it has to be checked whether this message is the beginning of a new scenario or the continuation of one or more scenarios under monitoring. Unless the path of consecutive messages is not unique, several scenarios remain as candidates.

Under real-world conditions, a large number of different concurrent scenarios may be monitored simultaneously, some still open to a final decision. For example, each occur- rence of a B1 message in Figure 7.4 initiates a new instance of a scenario monitor. A refinement of analysers is the assignment of time intervals to the arrows connecting two messages. This defines how long the monitor waits for the continuation of a scenario. If the expected future is not confirmed within a given time frame, tracing of the scenario is cancelled and an error is reported: Either the scenario has not been specified properly or the flow of messages between two or more parties is faulty due to misbehaviour of one or more communication partners. Message sequences that cannot be assigned to scenarios indicate underspecification.

The composition and abstraction mechanisms of CFR models may not only be applied to abstract protocols but also to scenarios. A sub-scenario is a communication pattern and abstracted using a message on a higher level. This approach is open-ended and allows stepwise definition of more complex scenarios through layering.

7.5.2 Reproducing Complex Scenarios for Test Automation

The previous subsection described monitoring and verifying complex scenarios. These techniques may be used to reproduce complex scenarios with the aim to automate system tests by simulating systems components. The key is to define a trigger message that starts a use case. For example, in the case of a braking manoeuvre the initial trigger is the anti lock brake activation. A certain initiation message and system state define the expected scenario. If this scenario can be reproduced from the messages on the bus the test case succeeds. The testing process can be divided into the following stages:

1. selecting standard protocols on which abstract protocols are defined 2. defining message interfaces, e.g., the output of a protocol analyser 3. defining abstract protocols based on standard protocols

4. specifying test scenarios as communication patterns on abstract protocols 5. associating triggers and system state with expected scenarios

6. sending triggers and attempting to reconstruct the scenario 7. monitoring of the system in case of failure to discover fault

Setting up the system state for a test scenario may involve the use of message gen- erators and simulators that replace actual components. As described earlier, this can be achieved through a “downwards” mapping from an abstract protocol to a concrete proto- col.

7.5.3 Relevance for Different Stages of the Development Process

The CFR approach provides support for several different stages of the software develop- ment process. The contributions are visualised using the V-Model, a widely used process model for software development in the automotive domain in Figure 7.5.

The most apparent contribution of a protocol analyser in the software development process is message level analysis. The message level can be associated to the Module level in the V-Model. This is where unit-testing takes place and where it is assured that system modules act in the desired way. Analysers generated from CFR models validate the correct communication behaviour between modules.

The approach presented extends the scope of protocol analysis to complex scenarios. Analysers for scenarios and abstract protocols validate the correct behaviour of system

Customer Requirements System Requirements SW Requirements SW Module Requirements SW Component Requirements System Delivery

System Test & Integration SW Subsystem Test SW Component Test SW Module Test SW Implementation SW Design SW Component Design

Specification on

message level

A priori specification

on scenario and

abstract protocol level

A posteriori analysis on

message level

A posteriori analysis on

scenario and abstract

protocol level

Figure 7.5: Identification of Possible Application Areas using the V-Model

components and the system itself. This contributes to the system test level and also at the component test level of the V-Model. With the capabilities of monitoring message flows and learning from them, it is possible to document and specify different parts of a distributed system. Network protocols may be specified by observing the communication on the message level. Complex Scenarios may be specified by monitoring messages in a broader context, concerning components of a network system or the whole system itself. Accordingly, there are two different types of analysis:

• Analysis with a priori knowledge • Analysis with a posteriori knowledge

The challenge in the first case is to uncover underspecification in a given explicit speci- fication. In the second case, design intentions of an implicit specification, e.g., an imple- mentation, are made visible.