SAE ARP 6227-2013 JAUS Messaging over the OMG Data Distribution Service (DDS)《通过OMG数据分配服务(DDS)的JAUS消息传送》.pdf

《SAE ARP 6227-2013 JAUS Messaging over the OMG Data Distribution Service (DDS)《通过OMG数据分配服务(DDS)的JAUS消息传送》.pdf》由会员分享，可在线阅读，更多相关《SAE ARP 6227-2013 JAUS Messaging over the OMG Data Distribution Service (DDS)《通过OMG数据分配服务(DDS)的JAUS消息传送》.pdf（18页珍藏版）》请在麦多课文档分享上搜索。

1、_ SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising there

2、from, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and suggestions. Copyright 2013 SAE International All rights reserved. No part of this p

3、ublication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: +1 724-776-497

4、0 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org SAE values your input. To provide feedback on this Technical Report, please visit http:/www.sae.org/technical/standards/ARP6227 AEROSPACE RECOMMENDED PRACTICE ARP6227 Issued 2013-02 JAUS Messaging over

5、 the OMG Data Distribution Service (DDS) RATIONALE The AS5684A standard defines the JAUS Service Interface Definition Language (JSIDL) that, in part, specifies the serialization of JAUS messages that can be exchanged over multiple transports like JAUS-over-UDP (JUDP). This ARP6227 document defines a

6、 mapping of the JSIDL messageset and typeset schema elements to OMG Interface Definition Language (IDL) used by the OMG Data Distribution Service (DDS) standard. DDS provides a standard transport layer with interoperable support by multiple vendors. JAUS users have been moving toward implementing JA

7、US services over alternate transports, and significant new systems have already started integrating JAUS messaging over DDS. This ARP allows the JAUS community to begin hosting JAUS on interoperable DDS transports, and opens the discussion for continuing work on transport considerations that might p

8、roduce a JAUS / DDS standard. This document alone is NOT sufficient to create a JAUS compliant or interoperable JAUS implementation. SAE ARP6227 Page 2 of 18 TABLE OF CONTENTS 1. SCOPE . 3 2. REFERENCES . 3 2.1 Applicable Documents . 3 2.1.1 SAE Publications 3 2.1.2 Object Management Group (OMG) Pub

9、lications . 3 3. OMG DDS INTERFACE DEFINITION LANGUAGE (IDL) 4 4. JSIDL to DDS IDL Mapping 4 4.1 Using JAUS() Annotations in DDS IDL . 6 4.2 JAUS DDS IDL Support for JAUS presence vectors for JSIDL Records and Sequences 6 4.3 JSIDL Declared Type Set . 7 4.4 Simple Fields . 7 4.4.1 Fixed Field . 8 4.

10、4.2 Variable Field 9 4.4.3 Bit Field . 9 4.4.4 Fixed-Length String Field 10 4.4.5 Variable-Length String Field . 10 4.4.6 Variable-Length Field 11 4.4.7 Variable-Format Field 11 4.5 Composite Fields 12 4.5.1 Array 13 4.5.2 Record . 13 4.5.3 List . 14 4.5.4 Variant . 15 4.5.5 Sequence 16 5. NOTES 18

11、FIGURE 1 COMPARISON OF A SIMPLE JAUS MESSAGE IN JSIDL AND DDS IDL . 5 TABLE 1 JSIDL - DDS IDL PRIMITIVE DATA TYPE MAPPING . 8 TABLE 2 JAUS COMPOSITE FIELDS MATRIX 12 SAE ARP6227 Page 3 of 18 TYPOGRAPHICAL CONVENTIONS The type styles shown below are used in this document to distinguish programming st

12、atements from ordinary English. However, these conventions are not used in tables or section headings where no distinction is necessary. Arial - 10 pt.: Standard body text Courier - 10 pt. Bold: Programming language elements. 1. SCOPE This document defines a standard representation of JAUS AS5684A m

13、essage data in DDS IDL defined by the Object Management Group (OMG) CORBA 3.2 specification. This document does NOT address how JAUS transport considerations or JAUS service protocols are implemented on OMG DDS platforms. 2. REFERENCES 2.1 Applicable Documents The following publications form a part

14、of this document to the extent specified herein. The latest issue of SAE publications shall apply. The applicable issue of other publications shall be the issue in effect on the date of the purchase order. In the event of conflict between the text of this document and references cited herein, the te

15、xt of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained. 2.1.1 SAE Publications Available from SAE International, 400 Commonwealth Drive, Warrendale, PA 15096-0001, Tel: 877-606-7323 (inside USA

16、 and Canada) or 724-776-4970 (outside USA), www.sae.org. AS5684A JAUS Service Interface Definition Language, July 2010 2.1.2 Object Management Group (OMG) Publications Available from the Object Management Group at the URL provided. CORBA3_2 Common Object Request Broker Architecture (CORBA), Specific

17、ation, Version 3.2, Part 1: CORBA Interfaces, November 2011. OMG Document Number: formal/2011-11-01 Standard document URL: http:/www.omg.org/spec/CORBA/3.2/Interfaces/PDF DDS1_2 Data Distribution Service for Real-time Systems Version 1.2, January 2007. OMG Document Number: formal/07-01-01 Standard d

18、ocument URL: http:/www.omg.org/spec/DDS/2.1 DDS_XTYPES Extensible and Dynamic Topic Types for DDS (DDS-XTypes), v1.0 OMG Document Number: formal/2012-11-10 Standard document URL: http:/www.omg.org/spec/DDS-XTypes/1.0/PDF SAE ARP6227 Page 4 of 18 3. OMG DDS INTERFACE DEFINITION LANGUAGE (IDL) As of D

19、DS1_2, data structures defined for the OMG Data Distribution Service (DDS) comply with interface definition language (IDL) defined by CORBA3_2. DDS vendors often extend this IDL to provide features requested by customers. In response, the OMG DDS group has recently published DDS_XTYPES to provide si

20、gnificant new functionality, including support for bitfields (BitFieldType) and value initialization. Because it will take some time for this new standard to be fully supported by DDS providers, the JAUS/DDS IDL mappings will conform to CORBA3_2. The JAUS/DDS task group will track developments with

21、DDS XTypes and address in future versions of this and other documents. 4. JSIDL TO DDS IDL MAPPING This document describes an approach for converting Joint Architecture for Unmanned Systems (JAUS) message types defined in a JAUS Service Interface Definition Language (JSIDL) file into corresponding D

22、ata Distribution Service (DDS) data types defined in a DDS IDL file. Using this approach results in DDS data types that can then be compiled by a DDS IDL compiler and the resultant code used to create JAUS over DDS (JDDS) topics. A sample JSIDL definition of a JAUS message compared with the correspo

23、nding DDS IDL definition is shown in Figure 1. The DDS IDL representation of JAUS messages makes heavy use of module declarations to segregate the namespace and avoid name collisions, since JAUS fields can be reused in multiple contexts within the same message: 1. All JDDS data types are defined wit

24、hin a JDDS module. 2. Each JAUS message type is defined within a separate module. The name is taken from the name attribute of the message_def element in the JSIDL. For example, note the message_def element in the JSIDL below named SimpleMessage and the corresponding module SimpleMessage declaration

25、 in the DDS IDL. 3. Each JAUS message contains a header, body, and footer segment. Each of these segments is defined in a separate module with a corresponding name. 4. Each JAUS composite field type is defined in a separate module. The name is taken from the name attribute of the corresponding compo

26、site field element in the JSIDL. For example, note the record element in the JSIDL below named SimpleRecord and the corresponding module SimpleRecord declaration in the DDS IDL. 5. JAUS data properties that cannot be represented in standard CORBA IDL can optionally be provided as annotations enclose

27、d in JAUS(). This is an optional feature of JSIDL / IDL translators that allows development tooling to use the additional JAUS properties from JSIDL as represented in the IDL. SAE ARP6227 Page 5 of 18 FIGURE 1 - COMPARISON OF A SIMPLE JAUS MESSAGE IN JSIDL AND DDS IDL Each of the JSIDL composite typ

28、es has a corresponding typedef in the DDS IDL. These typedefs are then used in the declaration of a DDS structure named Message toward the end of the DDS IDL file listed above. The Message structure forms the actual DDS data type that will be used to create JDDS topics corresponding to the associate

29、d JAUS message. The Message structure contains members for the header, body, and footer. In the above example, the footer is empty, so no element is included for the footer. The Message structure also contains a declaration of the source JAUS address. The source address is used as the key for the DD

30、S data type. A particular JAUS message type may be sent by multiple components in the system. Designating the source address as the key field allows JDDS messages of the same type published by two different JDDS components to form separate DDS instances and, therefore, be distinguished from one anot

31、her. The Message structure also contains a declaration of the destination JAUS address. The destination address allows subscribers to filter JDDS messages, ignoring those directed to another JDDS component. JAUS messages may also be broadcast locally to all JAUS components within a JAUS subsystem by

32、 setting the component ID and node ID of the destination address to 0xFF. Global broadcasts to all JAUS components in all JAUS subsystems may be made by also setting the subsystem ID to 0xFFFF. Simple Server used for unit testing during JDDS development and testing module SimpleServer / JAUS(id=“urn

33、:jaus:exp:dds:SimpleServer“, version=“1.0“) / Simple Server used for unit testing during JDDS development and testing module JDDS / / message / module SimpleMessage / JAUS(query,id=B001) typedef struct JausAddress unsigned short SubsystemID; octet NodeID; octet ComponentID; JausAddress_; module head

34、er typedef struct HeaderRec unsigned short MessageID; HeaderRec_; ; module body module SimpleRecord typedef struct SimpleRecord long SimpleFixedField; / JAUS(units=“one”,required) SimpleRecord_; ; ; struct Message JausAddress_ source; JausAddress_ destination; header:HeaderRec_ JTS_Header; body:Simp

35、leRecord:SimpleRecord_ SimpleBody; ; / pragma is an OpenSplice element, RTI and / others identify keys differently. DDS XTypes / has a standard annotation for keys. #pragma keylist Message source.SubsystemID source.NodeID source.ComponentID ; / message: SimpleMessage ; ; SAE ARP6227 Page 6 of 18 The

36、 DDS IDL in Figure 1 shows an example of a JAUS DDS message keyed by its source JAUS identifier using the OpenSplice syntax (#pragma). This document defines how data in message payloads is mapped from JSIDL to DDS IDL and does not mandate specific DDS implementation decisions about DDS Topics, Topic

37、 types, and Topic type keys. Such decisions may be the subject of a future specification. DDS allows topic data types to have key fields defined DDS1_2. DDS IDL does not specify a standard way to annotate IDL to specify key fields. The example in Figure 1 shows the use of source.SubsystemID, source.

38、NodeID, and source.ComponentID as keys for all JAUS-DDS topics. JSIDL to DDS IDL processing software should take this into account, possibly with options to generate IDL with extensions for multiple popular DDS middleware IDL processors. 4.1 Using JAUS() Annotations in DDS IDL The JSIDL XML schema s

39、upports a much richer set of information that the CORBA3_2 IDL grammar supports. Any JAUS DDS IDL created per this Aerospace Recommended Practice (ARP), MUST have an associated, complete and valid JSIDL specification. The JSIDL specification is authoritative in all respects. With that in mind, it is

40、 helpful to include some of the JSIDL information in JAUS DDS IDL to improve readability and understandability. This is done through the use of annotations embedded in comments per the following rules: 1. All annotations are optional. 2. If an annotation disagrees with the corresponding JSIDL, the J

41、SIDL is correct. 3. Every annotation is embedded in a comment and enclosed with JAUS(). 4. An annotation contains a list of tokens or name-value pairs. String values are quoted. For example: JAUS(units=”meter”,range=”(0.0,1.0”,required). 5. Numeric value ranges in JSIDL can have open (exclusive) or

42、closed (inclusive) boundaries. In the JAUS DDS annotations, we use the convention of parends for open boundaries and square brackets for closed boundaries. For example, in the previous case range=”(0.0,1.0” denotes all values x such that x 0.0 and x , the notion of optional has no meaning. Even thou

43、gh JSIDL will still have an optional attribute in the definition, it is the optional attribute in the container where the declared_type is referenced that determines whether an item is optional or not. In JAUS DDS IDL, there is no optional or required annotation in any typedef item. The optional=N a

44、nd required annotations are only required in the context of a record or sequence where a presence_vector can appear. 4.3 JSIDL Declared Type Set The JSIDL schema provides for predefined types in a element. Elements in a JSIDL are rendered as standalone typedefs that can be referenced as normal types

45、 elsewhere in the DDS IDL. The JAUS URN namespace is reproduced in the DDS module namespace. For example: JSIDL Representation DDS IDL Representation: The following sections detail how each specific JSIDL field type is mapped to DDS IDL. 4.4 Simple Fields JAUS provides seven different types of simpl

46、e fields. According to the JSIDL specification (AS5684), “A Simple Field is an abstract data type that must be used to specify a single cohesive unit of data that cannot be further divided into two or more Simple or Composite Fields.” The following sections present JSIDL representations of each simp

47、le field type and describe the mapping to DDS IDL. Many JSIDL simple field types map directly to a primitive type in the DDS IDL as shown in Table 1. module sample module BasicTypes typedef long SimpleFixedField; / JAUS(units=“one”) SAE ARP6227 Page 8 of 18 TABLE 1 - JSIDL - DDS IDL PRIMITIVE DATA T

48、YPE MAPPING The JSIDL specification AS5684A should be referenced for details on the usage, available options and range of values for each of the simple fields. 4.4.1 Fixed Field “A fixed_field represents a primitive data type whose type and units are fixed.” AS5684A The primitive data type for a fix

49、ed field is one of the JSIDL Primitive Data Types given in Table 1, indicated by the value of the field_type attribute of the fixed_field element. The corresponding DDS IDL Primitive Data Type in Table 1 is used as the DDS type of the fixed field element.” JSIDL Representation DDS IDL Representation: JSIDL fixed