Chapter 9: Interprocess Communication
10.6 Notification Mechanisms
OSEK/VDX COM notifies an application of the state of a message using one of four notifica-tion mechanisms: activate a task, set an event, call back a funcnotifica-tion, and set a flag. Activate a task and set an event require an OS that provides specific services for the mechanism. An OSEK/VDX OS provides these services but is not required for COM to operate. The last two mechanisms are intended for use in an application with either no OS or with an OS that does not support the first two mechanisms. Even if an OS that supports the first two mechanisms is used, the last two mechanisms can still be used.
Notification Mechanisms
141
The actions taken by the OS when a task is activated are specific to the OS. However, a task typically is moved into a state where it is ready to be executed. Based on the priority of the task, the task can execute immediately or some time in the future. Similarly, setting an event behaves differently in different OSs, but typically, the OS releases a task that is waiting for the event to occur and allows the task to execute in the future.
Figure 10.7 Mixed transmission mode deadline monitoring.
Mixed()
142
Chapter 10: CommunicationFigure 10.8 Periodic message reception deadline monitoring.
The mechanisms of callback and flag were added in the COM v2.2 specification. Because the goal of COM was to create a specification that could stand on its own, a method to notify an application not using an OS was required. Under the callback mechanism, the COM com-ponent executes a function when a notification is to occur. This function must have the fol-lowing C prototype.
void CallbackFunc(void);
BecauseCallbackFunc() is executed immediately when notification is required, it could be evoked at the interrupt level if the COM component determines that notification is required from within an ISR, which could affect interrupt latency.
The flag mechanism works in an OS that polls the status of messages from within tasks that are executed either in a round-robin or a time-sliced executive. API services that check the status of the flag and reset the flag were added.
Notify()
Msg_Received()
Msg_Received()
Msg_Frame() Msg_Received()
Monitor Monitor
Msg_Received()
Msg_Received()
Msg_Received()
Msg_Frame()
Notify()
Monitor Monitor
Msg_Received()
Msg_Received() Application
Interaction Layer
Network Layer
Data Link
Layer Network
Start()
First_Timeout
Msg_Frame()
Notification Mechanisms
143
The COM specification also defines five classes of notification (Table 10.2). Within each of these classes, all notification mechanisms are available. A conditional version of the first class that limits execution of a notification, based on the condition of the data in the message, could be considered a sixth class. The available conditions are exactly the same as the condi-tions under which a direct message is transmitted in the mixed mode of transmission. The use of these notification classes is discussed in more detail in the following chapters.
Table 10.2 Classes of notification.
In the COM specification, it is possible to notify an application when a deadline monitor expires and also when a reception or transmission fails. The difference between these two notification methods is the time lag. A deadline error is not recognized until the timer expires, whereas an unsuccessful transmission is noted immediately from the data link layer. In earlier versions of the standard, only one notification mechanism was allowed per message, and only one action could be taken. For an unqueued message in the present version, multiple actions of the same type (e.g., activate task, set event) are allowed for each type of notification mech-anism employed. The implementation can optionally allow multiple types of action to be taken.
Class Class Name Description
1 Message reception Notification occurs when the message is received (can be conditional based on the value). For internal and internal–external messages, notification occurs when the message is sent.
2 Message transmission Notification occurs when the message is successfully transmitted over the physical layer.
3 Message reception error
Notification occurs when deadline monitoring of periodic received messages indicates that the message has not been received.
4 Message transmission error
Notification occurs when deadline monitoring of transmitted messages indicates that the message was not successfully transmitted.
5 USDT first frame indication
Notification occurs when the first frame of a USDT message is received. USDT messages are discussed later.
144
Chapter 10: Communication10.7 Conformance Classes
All of the message attributes discussed in this chapter lead to the concept of conformance classes, which is unique to OSEK/VDX. In Part 1, the conformance class was discussed as it relates to the OS. A COM conformance class is defined as a specific realization of the COM requirements that contain a defined set of services available for all messages in the applica-tion. Five conformance classes are available: CCCA and CCCB only support internal mes-sages, CCC0 and CCC1 support internal and external UUDT mesmes-sages, and CCC2 supports all types of messages. The attributes that define the conformance class are shown in Table 10.3.
Table 10.3 Communication conformance class determination.
An X indicates mandatory support of the attribute, and an O indicates optional support.
Each conformance class is discussed in more detail in the following chapters.
Note that queued messages are optional in CCC0 and CCC1. The consequence is that some implementations require you to use all of the features of CCC2 to obtain the queued message capability. Be careful of this fact when you search for an implementation.
Feature CCCA CCCB CCC0 CCC1 CCC2
UUDT X X X
USDT X
Internal messages X X X X X
External messages X X X
Unqueued messages X X X X X
Queued messages X O O X
Direct transmission mode X X X
Periodic transmission mode X X
Mixed transmission mode X X
Message reception
notification (1) X X X X X
Message transmission
notification (2) X X X
Message reception error
notification (3) X X
Message transmission error
notification (4) X X
USDT first frame indication
notification (5) X
Message resource supported X X X X
Dynamic addressing X
Dynamic size X
Example Program
145
10.8 Example Program
The example program that was created in Part 1 was not modified in this chapter because I only provide an overview of the COM specification. Changes are made in the following chap-ters as messages are covered in depth.
10.9 Summary
In this chapter, I covered a lot of information concerning the attributes of messages. If your head is not spinning, then you are one of the few in the world who understand this subject the first time! Don’t worry, each area is discussed in more detail in the following chapters as I consider each type of message and use the attributes in examples.
146
Chapter 10: Communication This Page Intentionally Left Blank147
11
Chapter 11
Internal Communication
As seen in the last chapter, the OSEK/VDX COM specification describes a complex system with many levels of capability. To better understand how a COM implementation works, I dive deeper in this chapter into different types of communication, starting with internal com-munication. Internal communication is supported in all conformance classes, with CCCA and CCCB offering internal intertask communication only.
As with all of the OSEK/VDX specifications, COM is never complete. In the chapters of Part 2, I identify issues that could cause concern in the use of COM, and as I develop the chapters, I discuss ways to work around these concerns.
Throughout this and the succeeding chapters, the examples I develop use OSEK/VDX OS tasks to illustrate how communication works. If your application does not use an OSEK/VDX OS, these tasks can be replaced with functions or tasks for the OS being used, and you can ignore the task OIL configuration file listings.
11.1 Internal Communication Overview
Internal communication describes the function of a system when tasks communicate exclu-sively with each other within a single microcontroller. By definition, a physical network does not exist in the application. COM conformance classes CCCA and CCCB allow only internal communication. A COM component that operates in CCCA or CCCB implements only the interaction layer and not the network or data link layers. This is the smallest implementation available.