SAE AIR 6521-2016 Unmanned Systems (UxS) Control Segment (UCS) Architecture Data Distribution Service (DDS) (Includes Access to Additional Content).pdf

《SAE AIR 6521-2016 Unmanned Systems (UxS) Control Segment (UCS) Architecture Data Distribution Service (DDS) (Includes Access to Additional Content).pdf》由会员分享，可在线阅读，更多相关《SAE AIR 6521-2016 Unmanned Systems (UxS) Control Segment (UCS) Architecture Data Distribution Service (DDS) (Includes Access to Additional Content).pdf（9页珍藏版）》请在麦多课文档分享上搜索。

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 2016 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:/standards.sae.org/AIR6521 AEROSPACE INFORMATION REPORT AIR6521 Issued 2016-12 Unmanned Systems (UxS) Control Segm

5、ent (UCS) Architecture: Data Distribution Service (DDS) RATIONALE This document is the SAE publication of the Department of Defense UAS Control Segment (UCS) Architecture Interface Control Document: Data Distribution Service (DDS) User Guide approved for Distribution A public release 15.S-1859. TABL

6、E OF CONTENTS 1. SCOPE 2 2. REFERENCES 2 2.1 Applicable Documents 2 2.1.1 SAE Publications . 2 2.1.2 Object Management Group (OMG) Standards . 2 3. APPROACH 2 3.1 Example DDS Implementation Decisions . 3 3.1.1 Concern: Primitive Types 3 3.1.2 Concern: Array Bounds for Unbounded Model Elements . 3 3.

7、1.3 Concern: Structure 3 3.1.4 Concern: Compilation Support 4 3.1.5 Concern: Model Hierarchy Mapping 4 3.1.6 Concern: DDS Type Instance Uniqueness . 4 3.1.7 Concern: Measurement Value Concrete Types 4 3.1.8 Concern: DDS Topic Label Specification 4 3.2 Measurement Type Default Decisions Options . 4 3

8、.2.1 ICD Format 5 3.2.2 Optional Measurement Mappings . 5 3.3 Multiple Refinement Handling . 6 3.3.1 Status Message Handling . 6 3.3.2 Command Message Handling . 6 4. DDS IMPLEMENTATION MAPPING 7 4.1 UCSStatusTypes . 7 4.2 UCSCommandTypes 7 4.3 UCSRequestTypes 8 5. NOTES 8 5.1 Revision Indicator 8 A

9、PPENDIX A 9 SAE INTERNATIONAL AIR6521 Page 2 of 9 1. SCOPE This platform specific Interface Control Document (ICD) provides an example mapping to the Object Management Groups (OMG) Data Distribution Service (DDS) infrastructure middleware. The mapping is based on the Unmanned Systems (UxS) Control S

10、egment (UCS) Architecture: Model, AS6518. A series of non-normative implementation choices have been made that are specific to this ICD. These implementation choices may not be appropriate for different system implementations. The machine readable ICD and result of this mapping and implementation ch

11、oices are provided with AIR6521. Use and understanding of this document assumes a working knowledge of the UCS Architecture, the model structure and its contents. 2. REFERENCES 2.1 Applicable Documents The following publications form a part of this document to the extent specified herein. The latest

12、 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 text of this document takes precedence. Nothing in this docum

13、ent, 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 and Canada) or +1 724-776-4970 (outside USA), www.sae.org.

14、 AS6518 Unmanned Systems (UxS) Control Segment (UCS) Architecture: Model AS6512 Unmanned Systems (UxS) Control Segment (UCS) Architecture: Architecture Description AIR6514 Unmanned Systems (UxS) Control Segment (UCS) Architecture: Interface Control Document (ICD) 2.1.2 Object Management Group (OMG)

15、Standards Interface Description Language (IDL) and DDS standards are available from the Object Management Group, www.omg.org. OMG IDL Interface Definition Language, Version 4.0, OMG Document Number: formal/2016-04-02, Standard document URL: http:/www.omg.org/spec/IDL/4.0/ Extensible and Dynamic Topi

16、c Types for DDS (DDS-XTypes) Version 1.0 (OMG 2012) OMG DDS Data Distribution Service for Real-time Systems, V1.2 (OMG 2007) The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification, Version 2.1 (OMG 2009) 3. APPROACH The DDS ICD example was created by transform

17、ing the UCS Model, AS6518, Service and Service Interfaces leveraging a simple set of system-specific implementation and optimization choices. The example derives from the model, adding no content except implementation-specific choices. The UCS Model contains all documentation and reference notes on

18、the services, their interfaces, and messages. To generate the platform specific DDS representation, several system and implementation specific optimizations were considered. The following list summarizes several of the considerations that should be analyzed given system specific concerns when creati

19、ng an implementation of the UCS Architecture services and interfaces on DDS. SAE INTERNATIONAL AIR6521 Page 3 of 9 Volatility of data: If specific values are determined to be slow changing or fixed at initialization, then one can choose to separate these values in the message structure so they can b

20、e sent or set only once. One may do this to apply different handling of quality of service to static data versus constantly changing dynamic data. Bandwidth optimization: Similar to data volatility, some considerations may be made to limit distribution of values that are not changing, or are changin

21、g at significantly different rates. Size of arrays and initializers: Different systems may have different configurations. System and implementation optimizations may choose not to pad unspecified array limits. Concrete type realizations: Implementation specific representations of reals and integers

22、as well as programming specific representations of addresses and identities. Communication patterns: Once the interface type structure is defined, additional system-specific considerations include the distribution pattern (e.g., pub/sub, request/response) for the message. By Value/By Reference: The

23、UCS Logical Data Model in the message specification designates at the logical level whether an attribute is the value of the projected element or a reference. All references are typed to AlphaNumericGUIDS. Depending on system design, additional optimizations may be made by passing data by reference

24、rather than by value. This implies a mechanism to store, cache, and distribute the reference data. Another design consideration is that pass by value and pass by reference implementations have different views of current state and when a sampled value is actually viewed and processed. 3.1 Example DDS

25、 Implementation Decisions The following sections detail the implementation choices made when mapping the Unmanned Systems (UxS) Control Segment (UCS) Architecture: Model to a DDS specific and compilable representation. These choices were made to provide an implementation on DDS of the UCS service in

26、terfaces that is straightforward, with limited optimization and no system specific customization. 3.1.1 Concern: Primitive Types The model definitions for value representation are mapped as follows: typedef string AlphaNumericGUID; typedef char Character; typedef long Integer; typedef double Real; t

27、ypedef double Coordinate; typedef string String; 3.1.2 Concern: Array Bounds for Unbounded Model Elements In order to limit unmanaged memory utilization, unspecified array bounds are initialized to a default value. These values are captured as constants in a separate IDL file for convenience when ap

28、plying system specific values and settings. Upper/lower measurements specifications default = 3 For all other array limits default = 7 3.1.3 Concern: Structure The IDL language provides a mechanism to inherit attributes. In order to minimize dependency on hierarchical IDL definitions, this is not us

29、ed, and data structure specifications inline all inherited attributes. This has an impact on code size but simplifies compilation dependencies. Inline all attributes from parent type specification. Inline into a single IDL structure specification for the UCS service interface operation parameter typ

30、e. SAE INTERNATIONAL AIR6521 Page 4 of 9 3.1.4 Concern: Compilation Support In order to support compilation, the following name and type mappings are made. Enumeration value labels must be unique. Postpend the enumeration type name to the enumeration label to avoid name collision. Dashes in variable

31、 names become underscores. Empty classes get a dummy field to appease IDL parsing and code generation. 3.1.5 Concern: Model Hierarchy Mapping Representing the model structure is critical to maintaining and understanding the message context. Where appropriate, the following model structure implementa

32、tion mappings are made. Circularly dependent attributes become references. Entities from the projection path are added as references in the DDS IDL type specification. If another reference to a model element is needed, it is assumed to be explicitly defined in the interface message type specificatio

33、n. 3.1.6 Concern: DDS Type Instance Uniqueness In order to leverage the capabilities of DDS, information regarding the identity of types is provided by specifying attribute fields as keys. The model elements projected to an interface types projection path specification become key fields. All referen

34、ce and key types become AlphaNumericGUIDs. 3.1.7 Concern: Measurement Value Concrete Types In all cases, the type of a measurements representation is replaced by the described valueKind. 3.1.8 Concern: DDS Topic Label Specification DDS binds a message definition (the IDL type) to a Topic for discove

35、ry and dissemination. Depending on memory, bandwidth utilization, and flexibility constraints, different mappings can be made. In this example, the choice was for maximum flexibility and data availability. In all cases, the DDS topic for each type specification is the corresponding services interfac

36、es operation name, prepended with the service name for uniqueness. 3.2 Measurement Type Default Decisions Options There are several choices when it comes to handling the measurement configuration data. Considerations include possibility of bandwidth or processing constrained environments and differe

37、nt configuration distribution mechanisms. For this ICD generation, the choice was to minimize distribution of static measurement data and simplify type specification for the complier with a typedef. The schema configuration data is captured in the type annotation and can be further processed to make

38、 available to support configuration services. SAE INTERNATIONAL AIR6521 Page 5 of 9 3.2.1 ICD Format Measurement specifications for this example DDS ICD are represented as a typedef to the concrete language specific type. Additionally, the AS6518 interface specifications of the measurement reference

39、 frame or coordinate tuple coordinate reference system are provided as an annotation on the measurement type definition. The annotation format follows the Extensible and Dynamic Topic Types for DDS (DDS-XTypes) Version 1.0 Specification and is provided for tool post processing and configuration init

40、ialization. typedef Real GeodeticLatitude; / UCS(“axisAbbrev=Latitude, axisDirection=north, / axisUnit=Radian, / maximumValue=1.5707963267948966192313216916398, / minimumValue=-1.5707963267948966192313216916398, / rangeMeaning=exact,resolution=0.0000000001“) struct GeodeticLatitude_Tuple /UCS(coordi

41、nateReferenceSystem=“GeodeticPosition2D“) /GeodeticLatitude_Tuple specifies the angle between the normal and the /equatorial plane of the ellipsoid. The Latitude specifies the north-south /position of a point. GeodeticLatitude latitude; ; struct Position2D_Tuple /Position2D_Tuple specifies a locatio

42、n on the surface of the Earth. GeodeticLatitude_Tuple geodeticLatitude; /geodeticLatitude specifies the north-south coordinate of the position. GeodeticLongitude_Tuple geodeticLongitude; /geodeticLongitude specifies the east-west coordinate of the position. ; 3.2.2 Optional Measurement Mappings Depe

43、nding on compiler support, bandwidth, flexibility, and other implementation specific considerations, the following could be provided by an implementation to highlight additional possibilities for MeasurementType mappings to IDL. These are not used and are not represented in the generated DDS IDL. In

44、line all data. Send measurement descriptions (e.g., precision, referenceFrame, units) with every value update. Completely expressive and fully defined but sends possibly repetitive data. struct Altitude_WGS84_Meters_1eNeg3_Type / from MeasurementType UCSInitializer(“1e-3“) PrecisionType precision; U

45、CSInitializer(“WGS-84_MSL“) ReferenceFrameType referenceFrame; UCSInitializer(“Meters“) UnitsType units; UCSInitializer(“Real“) ValueType valueKind; Real value; ; SAE INTERNATIONAL AIR6521 Page 6 of 9 Measurement specification is represented as a typedef to the concrete language specific type. Addit

46、ionally, the AS6518 model specifications of the measurement are provided as a configuration structure (_Config) that could also be passed or distributed as needed. typedef Real Speed; / UCS(“fractionDigits=6,units=MeterPerSecond“) typedef Speed TrueAirspeed_STP_Measurement; /UCSInitializer(reference

47、Frame=“STP“) struct TrueAirspeed_STP_Measurement / from MeasurementType UCSInitializer(“1e-6“) PrecisionType precision; UCSInitializer(“STP“) ReferenceFrameType referenceFrame; UCSInitializer(“MeterPerSecond“) UnitsType units; UCSInitializer(“Real“) ValueType valueKind; ; Use presence fields in data

48、 structure. Mark measurement descriptions as optional. Leverages the Dynamic Topic Types for DDS Version 1.0 Specification, which is not supported by all DDS vendors. Also uses annotation to specify the initial value. struct TrueAirspeed_STP_Measurement / from MeasurementType UCSInitializer(“1e-6“) PrecisionType precision; UCSInitializer(“STP“) ReferenceFrameType referenceFrame; UCSInitializer(“MeterPerSecond“) UnitsType units; UCSInitializer(“Real“) ValueType valueKind; Real value; ; 3.3 Multiple Refinement Handling In some cases, attributes in message