Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 33
Текст из файла (страница 33)
An example of such a standardization effort is the SAE J 1587 MessageSpecification. The Society of Automotive Engineers (SAE) has standardized4.6 Linking Interface Specification99the message formats for heavy-duty vehicle applications in the J 1587 Standard. Thisstandard defines message names and parameter names for many data elements thatoccur in the application domain of heavy vehicles. Besides data formats, the range ofthe variables and the update frequencies are also covered by the standard.4.6Linking Interface SpecificationAs noted in Sect. 4.1.1, the timed sequence of messages that a component exchangesacross an interface with its environment defines the behavior of the component atthat interface [Kop03]. The interface behavior is thus determined by the propertiesof all messages that cross an interface. We distinguish three parts of an interfacespecification: (1) the transport specification of the messages, (2) the operationalspecification of the messages, and the (3) the meta-level specification of themessages.The transport specification describes all properties of a message that are neededto transport the message from the sender to the receiver(s).
The transport specification covers the addressing and temporal properties of a message. If two componentsare linked by a communication system, the transport specification suffices todescribe the requested services from the communication system. The communication system is agnostic about the contents of the data field of a message. For thecommunication system is does not matter whether the data field contains multimedia data, such as voice or video, numerical data or any other data type.Example: The Internet provides a defined message transport service between two endsystems, not knowing what types of digital data are transported.In order to be able to interpret the data field of a message at the end points of thecommunication, we need the operational and the meta-level specification.
Theoperational specification informs about the syntactic structure of the message thatis exchanged across the LIF and establishes the message variables. Both, thetransport and the operational specification must be precise and formal to ensurethe syntactic interoperability of components. The meta-level specification of a LIFassigns meaning to the message variable names introduced by the operationalspecification.
It is based on an interface model of the user environment. Since itis impossible to formalize all aspects of a real-world user environment, the metalevel specification will often contain natural language elements, which lack theprecision of a formal system. Central concepts of the application domains andapplications can be specified using domain specific ontologies.4.6.1Transport SpecificationThe transport specification contains the information needed by the communicationsystem to transport a message from a sender to the receiver(s). An interface contains1004 Real-Time Modela number of ports where the messages destined for this interface arrive or wheremessages are placed for sending.
The following attributes must be contained in thetransport specification:lllllPort address and directionLength of the data field of the messageType of message (e.g., time-triggered or event-triggered or data stream)Cycle of a time-triggered messageQueue depth for an event-triggered message or a data streamIt is a design decision whether these attributes are linked with the message or areassociated with the port where the message is handled.As noted above, the transport specification must contain the information aboutthe temporal properties of a message. For time-triggered messages, the temporaldomain is precisely specified by the cycle that is associated with every timetriggered message. For event-triggered messages, the temporal specification ismore difficult, particularly if event-triggered messages can arrive in bursts.
In thelong run, the message arrival rate must not be larger than the message consumptionrate by the receiver, since an event-triggered message must conform to the exactlyonce semantics (see Sect. 4.3.3). In the short run, an arriving message burst can bebuffered in the receiver queue until the queue is full. The specification of the properqueue length for bursty event-triggered messages is very important.4.6.2Operational SpecificationFrom the point of view of communication, the data field of an arriving message canbe considered as an unstructured bit vector. At the endpoints of the communication,the operational specification determines how this bit vector must be structured intomessage variables.
A message variable is a syntactic unit that consists of a fixedpart and a variable part (see Sect. 2.2.4). The information about how the data field ofa message is structured in syntactic units is contained in a message-structuredeclaration (MSD). The MSD contains the message variable names (i.e., thefixed part of the message variable) that point to the relevant concepts on oneside and, on the other side, specifies which part of the unstructured bit vectordenotes the value (the variable part) of a message variable. In addition to thestructure information, the MSD may contain input assertions for checking thevalidity of incoming data (e.g., to test if the data is within a permitted data domainthat the receiving component is capable to handle) and output assertions forchecking outgoing data.
An incoming data element that passes the input assertionis called a permitted data element. An outgoing data element that passes the outputassertion is called a checked data element. The formalism used for specifyingthe data structures and the assertions in the MSD depends on the availableprogramming environment.4.6 Linking Interface Specification101In many real-time systems the MSD is static, i.e., it does not change over thelifetime of the system. In these systems, for performance reasons, the MSD is nottransmitted in the message but stored in the memories of the communicatingpartners where the data fields must be handled.The link between the unstructured bit vector arriving at a port and the associatedMSD can be established by different means:lllllThe MSD name is assigned to the input port name.
In this case only a singlemessage type can be accepted at a port.The MSD name is contained in the data field of the message. In this case differentmessage types can be received at the same port. This approach is followed inCAN, (see Sect. 7.3.2).The MSD name is assigned to the cyclic arrival instant of a time-triggeredmessage. In this case different message types can be received at the same port,without the need to store the MSD name in the data field of the message. Thisapproach is followed in TTP see Sect. 7.5.1.The MSD name is stored in a server that can be accessed by the receiver of amessage. This approach is followed in CORBA [Sie00].The MSD itself is part of the message.
This is the most flexible arrangement, atthe cost of having to send the full MSD in every message. This approach isfollowed in service-oriented architectures (SOA) [Ray10].4.6.3Meta-Level SpecificationThe meta-level LIF specification assigns a meaning to the message variablesexchanged between two communicating LIFs at the operational level and thusestablishes semantic interoperability. It thus bridges the gap between the syntacticunits and the user’s mental model of the service provided at the interface. Central tothis meta-level specification is the LIF service model.
The LIF service modeldefines the concepts that are associated with the message variable names containedin the operational specification. These concepts will be qualitatively different forclosed components and open components (see Sect. 4.4.5).The LIF service model for a closed component can be formalized, since a closedcomponent does not interact with the external environment.
The relationshipbetween the LIF inputs and LIF outputs depends on the discrete algorithms implemented within the closed component. There is no input from the external environment that can bring unpredictability into the component behavior. The sparsetime-base within a cluster is discrete and supports a consistent temporal order ofall events.The LIF service model for an open component is fundamentally different since itmust encompass the inputs from the external environment, the local interfaces ofthe component in its interface specification. Without knowing the context of use ofan open component, only the operational specification of an open component can be1024 Real-Time Modelprovided.
Since the external physical environment is not rigorously definable, theinterpretation of the external inputs depends on human understanding of the naturalenvironment. The concepts used in the description of the LIF service model mustthus fit well with the accustomed concepts within a user’s internal conceptuallandscape (see Sect. 2.2); otherwise the description will not be understood.The discussion that follows focuses on LIFs of open components, since thesystems we are interested in must interact with the external environment.
The LIFservice model of an open component must meet the following requirements:lllUser orientation. Concepts that are familiar to a prototypical user must be thebasic elements of the LIF service model. For example, if a user is expected tohave an engineering background, terms and notations that are common knowledge in the chosen engineering discipline should be used in presenting themodel.Goal orientation.
A user of a component employs the component with the intentto achieve a goal, i.e., to contribute to the solution of her/his problem. Therelationship between user intent and the services provided at the LIF must beexposed in the LIF service model.System view. A LIF service user (the system architect) needs to consider thesystem-wide effects of an interaction of the component with the external physical environment, i.e., effects that go beyond the component.
The LIF servicemodel is different from the model describing the algorithms implemented withina component, since these algorithms are within the component’s boundaries.Example: Let us analyze the simple case of a variable that contains a temperature.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
