Attachment_0043_-_RAS-G_IOP_V2_Applique_Profile.pdf

Robotics and Autonomous Systems – Ground (RAS-G) Interoperability Profile (IOP)

Appliqué Profile Version 2.0

Program Manager Force Projection (PM-FP)

SFAE-CSS-FP MS 401

6501 East 11 Mile Road

Warren, MI 48397

February 2016

Distribution A: Approved for Public Release i

Contents 1 Scope

1.1 Purpose

2 Source Documents

2.1 Government Documents

2.2 Non-Government Documents

3 Key Concepts and Information

3.1 Definitions

3.2 System Context

3.2.1 Communications

4 Applique Core Attribute

4.1 Compliant/Non-compliant Interfacing

4.2 Communications

4.3 Electrical and Power Interfaces

4.4 Logical Interfaces

4.5 Physical Mounting Options

5 Future Directions for Applique Interoperability

5.1 Vehicle Categories

5.2 V2 Additions and Assumptions

5.3 Safety in Larger Systems

5.3.1 V3+ Considerations

6 Appendix A - Discussion of Technical Topics and Lessons Learned for Future Consideration

7 Appendix B: Autonomous Mobility Appliqué Kit (AMAS) IOP Messages Working Group Recommendations

Draft Recommended Messages to Support XBW & SAK Interface

Messages to XBW & SAK Interface

1 Background

2 Activity Goals

3 Assumptions

3.1 XBW Specific Assumptions

3.1.1 Configuration

3.1.2 Problems Addressed

3.1.3 Advantages

3.2 SAK Specific Assumptions

3.2.1 Configuration

ii

3.2.2 Problems Addressed

3.2.3 Advantages

4 Approach

5 Proposed Messages

5.1 Vehicle Parameters

5.2 Trailer Parameters

5.3 Trailer Hitch Parameters

5.4 Software & Hardware Info

5.5 Actuator State

5.6 Navigation Data

5.7 Advanced Emergency Braking System

5.8 Military Lighting Command

5.9 Vehicle Path

5.10 Secondary Controls

5.11 Health Status

5.12 Battery

5.13 Active Safety Modules

5.14 Engine Data

5.15 Platform Mode

5.16 Emergency Stop

5.17 Drive Mode

5.18 Time

6 Message Mapping to J1939

6.1 Vehicle Parameters

6.2 Actuator State

6.3 Navigation Data

6.4 Advanced Emergency Braking System

6.5 Military Lighting Command

6.6 Vehicle Path

iii

List of Tables Table 1-1: Relationship of the UGV IOP Profiling Documents Table 2-1: Government Documents Table 2-2: Non-government Documents Table 3-1: Definitions iv

List of Figures Figure 3-1: Reference Architecture Figure 3-2: Communications Architecture Figure 5-1: Relationship of the UGV IOP Profiling Documents with SAE J1939 Adoption

1 Scope

1.1 Purpose

This document is a normative attachment to the Robotics and Autonomous Systems – Ground (RAS-G) Interoperability Profile (IOP) Overarching Profile and provides specific rules and requirements associated with the profiling of Appliqué type robots to achieve system level and platform level interoperability. This document will prescribe guidance and considerations for the profiling of the Applique type robotic systems in order to achieve interoperability at various levels within a system.

Robotic appliqué for this document is defined as the application of sensors, hardware, and software to an existing manned platform to provide a cost effective remotely operated or autonomous capability that allows the vehicle to be optionally piloted/operated. The use of an existing system negates the need to develop a separate unmanned platform when the current manned system may be optimized for its role, such as cargo transport.

As depicted below in Figure 1-1, the JAUS Profiling Rules document forms a direct relationship with the RAS-G IOPs as well as the SAE JAUS standards.

Table 1-1: Relationship of the RAS-G IOP Profiling Documents

2 Source Documents

2.1 Government Documents

Table 2-1: Government Documents

RAS-G IOP SAE JAUS Profiling Rules RAS-G IOP Custom Services Messages and Transports RAS-G IOP Overarching Profile RAS-G IOP Communications Profile RAS-G IOP Payloads Profile RAS-G IOP Controls Profile

2.2 Non-Government Documents

Table 2-2: Non-government Documents

AIR5665A SAE Aerospace Information Report, Architecture Framework for Unmanned Systems (AFUS), April 2009.

IEEE 802.3-2008 Standards for Ethernet based LANs

3 Key Concepts and Information This section provides information on key document concepts, how to use this document to describe interoperability requirements, definitions, and other information. Only concepts pertaining to Appliqué type robots are presented here. Other RAS-G IOP document concepts are outlined in their respective document.

3.1 Definitions

Table 3-1: Definitions

Term Definition

Appliqué (Semi- Autonomous)

The augmentation of a manned vehicle such that it can be semi-autonomously controlled.

A-kit

The A-kit is comprised of the physical and electrical connections between the vehicle and the B-kit.

B-kit

The B-kit is a mountable unit that allows for dismount operations from afar with the use of an OCU. The semi-autonomous kit (SAK) will mount to the platform and connect the Mobile Base Unit to the Drive By Wire system.

Compliance Bridge

A compliance bridge is a piece of software that translates messages from IOP compliant components to non-compliant software components. (See the RAS-G Overarching Profile document (section titled “Non-compliance”.)

Mobile Base Unit (MBU)

The Mobile Base Unit (MBU) is contained within the SAK and contains the hardware and software needed to semi-autonomously control the vehicle. It has a RAS-G IOP compliant interface to the vehicle’s Vehicle Control Unit, and an RAS-G IOP compliant interface to the OCU via the radio.

The MBU will contain the necessary interfaces and computational algorithms to use additional payloads intended for increased situational awareness that augment the vehicle regardless of mounted or dismounted operations.

The MBU will have to have the ability to communicate with the vehicle sub-systems both sending and receiving data and control signals for correct operation of the vehicle through the X-By-Wire kit’s Vehicle control module (VCM). This will include sub-system controls and statuses. For example, the VCM will have to be able to control all of the drive sub-systems including steering, braking, acceleration, gear select, etc. and be able to report to the MBU the current status of each for semi-autonomy control. The MBU sends status to the OCU and receives commands from the operator through the OCU and then determines the correct semi-autonomy commands to send to the VCM for the vehicle to perform the mission safely.

Semi-autonomous

A mode of operation of an unmanned system wherein the human operator and/or the unmanned system plan and conduct a mission and require various levels of human robot interaction.

Semi-autonomous Kit (SAK)

The semi-autonomy kit is a combination of the MBU and any relevant sensors/payloads used for semi-autonomous control.

X-By-wire Kit (XBW)

This kit is resident within every vehicle that can be augmented with an applique kit. It is already integrated into the platform. This is where the translation to/from RAS-G IOP compliant interfaces and communication to the integrated vehicle sub-systems occurs.

Active safety functionality can be built into this kit (e.g.

obstacle avoidance).

Vehicle Control Module

(VCM)

This module is expected to be delivered with the vehicle by the Materiel Developer (MATDEV). As part of the XBW kit, it is the central point for command, control, active safety and any resultant feedback back to the SAK’s MBU.

3.2 System Context

Appliqué type systems have the ultimate goal of turning a manned vehicle into manned, unmanned or mixed manned and unmanned modes. In the case of it being manned, the augmented vehicle may free the operator(s) up in order to accomplish other tasking they would not otherwise be able to perform. It is through an add-on kit functionality that enables existing manned vehicles to be converted.

Figure 3-1 illustrates a notional reference architecture for an applique type system. There are two domains to any applique system. One domain is RAS-G IOP driven, and the other domain is Commercial-off-the-Shelf/Government-Furnished-Equipment (COTS/GFE) driven (i.e.

controlled by the vehicle manufacturer and/or the government PM of the manned system).

Vehicle manufacturers will deliver a vehicle with a XBW that has the ability to interface to the applique kits, which allows for semi-autonomous control in either the manned or unmanned modes.

This document proposes a reference architecture describing the breakdown of the individual pieces and where the dividing line between IOP and COTS/GFE is defined. Note that the reference architecture allows for flexibility in adding sensors and payloads to the RAS-G IOP compliant side of the system as new capabilities are built or researched, as well as the ability to tie into the on-board, delivered GFE payloads through a translation.

The Compliance Bridge is a translation layer for the logical interfaces, translating from RAS-G IOP compliant messages to non-compliant messages, and vice versa. This bridge is limited to data that needs to flow from one domain of the system to the other. It is located on or connected to the XBW kit, thus allowing vendors to develop their add-on kits without having to develop to the vehicle sub-system interfaces.

Figure 3-1: Reference Architecture

3.2.1 Communications

Communications within an applique system use the attributes as specified in the RAS-G IOP Communications Profiling Document. Figure 3-2 shows a notional system diagram of how communications between an OCU/other and the augmented vehicle occurs. The Common Communications Link (CCL) is not limited to point-to-point (as shown) but can be architected in any manner acceptable according to the RAS-G IOP Communications Profiling Document (i.e.

mesh/other).

Figure 3-2: Communications Architecture

4 Applique Core Attribute All applique type vehicles will follow the RAS-G IOP Applique Attribute as specified by the following sections each containing attributes that aid in describing the interoperable interfaces.

Where possible, references to the other RAS-G IOP Profiling documents will be cited.

Applique type systems have the unique problem of being driven by both the automotive industry, and the military robotics industry. As such, attributes set forth herein shall take this into consideration. When designing an appliqué system, care should be taken to separate the IOP compliant and non-compliant sides of the system. Compliance and how to deal with compliant/non-compliant interfacing is defined within the RAS-G Overarching Profile document (section titled “Non-compliance”).

4.1 Compliant/Non-compliant Interfacing

Parent Attribute: Applique Core Attribute

Any non-compliant portion of the system may be interfaced to a compliant portion of the system via wrapping or adapting. Adoption of a standard into the IOP is an alternative but may not meet the version of the IOP the system is being designed to. There is no guarantee that an adopted interface will be added to a future version of the IOP.

V2.APP.COMP-

1[Mandatory]

All compliant to non-compliant interfaces shall be wrapped or adapted as specified in the RAS-G IOP Overarching Profile document.

4.2 Communications

Parent Attribute: Applique Core Attribute

Communications interfaces on the vehicle will be driven by both the automotive industry and the RAS-G IOP Communications Profiling attributes. The RAS-G IOP will not specify the communications on the vehicle that are delivered by the vehicle manufacturer. Instead the RAS-G IOP will specify attributes for communications on the vehicle that drive the design of the applique kits. A translation bridge between the communications (both physical and logical) is necessary to translate from the IOP compliant side of the augmented vehicle to the non-compliant side.

V2.APP.COMM-

1[Mandatory]

The applique kits shall provide a communications interface to an OCU, and the XBW to MBU interface will comply with interface requirements as specified in the most current RAS-G IOP Communication Profile specification.

4.3 Electrical and Power Interfaces

Physical interfaces for electrical connections and power profiles for the vehicle are driven by both the automotive industry and the RAS-G IOP Payload’s Profile attributes. The IOP will only specify electrical connections and power profiles on the IOP compliant side of the system. If power for the applique kits is to be provided by the vehicle, the power will need to be conditioned to meet one of the power profiles as specified in the IOP.

V2.APP.PHYS.1

[Mandatory]

Electrical connections and power profiles should be profiled as specified in the most current RAS-G IOP Payloads Profile specification.

4.4 Logical Interfaces

Logical communications are defined to the extent possible using SAE JAUS service oriented architecture. The IOP has extended and profiled the SAE JAUS SOA through the RAS-G IOP JAUS Profiling and the RAS-G IOP Custom Services, Messages and Transports documents.

The IOP will only specify logical interfaces on the IOP compliant side of the system.

V2.APP.LOG.1

[Mandatory]

The logical interfaces within the system shall be provided utilizing SAE JAUS as profiled within the RAS-G IOP JAUS Profile and RAS-G IOP Custom Services, Messages, and Transports documents.

4.5 Physical Mounting Options

Physical interfaces for mounting payloads/other to the vehicle are driven by both the automotive industry and the RAS-G IOP Payload’s Profile attributes.

V2.APP.PAY.2

[Mandatory]

Physical Mounting options shall occur by one or more of the following:

ID Description

V2.APP.PAY.2

a[Selectable]

Physical mounting of a payload/other or other specified structure should comply with Physical Mounting Requirements as specified in the most current RAS-G IOP Payloads Profile specification.

V2.APP.PAY.2

b[Selectable]

Vehicle manufacturer may specify physical mounting requirements.

5 Future Directions for Applique Interoperability As stated above, appliqué type systems will be driven by both the military and vehicle manufacturers. As such, the future directions for this document are outlined in this section.

5.1 Vehicle Categories

Proposed vehicle categories for characterizing appliqué kits are included in Appendix A, Discussion of Technical Topics and Lessons Learned for Future Consideration.

5.2 V2 Additions and Assumptions

It is assumed in V2 that any appliqué system is of Category I. All attributes profiled to a program therefore use only V2 attributes as defined previously in this document and (Semi-) autonomous behaviors are limited to functioning under the conditions approved for Category I vehicles.

Additions to V2 for appliqué systems were identified via current program needs. These additions include new JAUS services and messages to handle operator control and feedback that translate to the appropriate vehicle messages. The appliqué-driven additions to IOP V2 include the following:

• Updates to lost communications policy (Overarching IOP & Comms IOP)

• Stability control (i.e. ABS, traction control, etc.) (Overarching IOP)

• Steering (i.e. crab/other) (Overarching IOP)

• Tire pressure and control (Overarching IOP)

• Wipers (Overarching IOP)

• Door locks (Overarching IOP)

• Debris blower (Payloads IOP)

• Drive train updates (i.e. 2WD/4WD, other) (Overarching IOP)

• Hydraulic and pneumatic actuators (Overarching IOP)

• Radar update (profiling for use with ground penetrating radar) (Payloads IOP)

• Helmet mounted display (Controls IOP)

• Illumination profiling for black out mode of operation (Controls IOP)

The IOP program works in conjunction with the SAE AS-4 JAUS committee. Custom messages and services are often introduced to the SAE’s committee for consideration.

5.3 Safety in Larger Systems

It is recognized that while the IOP does not concern itself with performance, larger faster moving vehicles will need to be taken into account when designing the reference architecture for an applique type system. Care should be taken to promote interoperability through common interfaces that aid in the ability to reach safety criticality and performance concerns.

As the IOP largely remains silent on issues of performance and safety, actual design or only physical, electrical, logical, and human-machine interfaces that promote safety and performance will be listed within the Applique IOP. Implementation details should be introduced into a companion document.

5.3.1 V3+ Considerations

Version 3 of the IOP will look closer in detail at the interfaces between the appliqué kits.

Additions to the Appliqué IOP will include those interfaces that will aid in reaching real-time safety critical implementations. Appendix B Figure 1 shows at a very high level where this focus is centered.

5.3.1.1 Logical Communications

Some areas that are currently being researched are in message sets and network protocols that promote safety critical concerns. From this research optional attributes for applique type systems will be consideration for V3.

5.3.1.1.1 Data Dictionary

In order to identify applique program needs a data dictionary of what information, status and control that needs to be exchanged will be compiled. The data dictionary is the starting point for profiling any standard message sets that would be adopted by the Appliqué IOP, and should be independent of the data bus being used (i.e. high-level description of what is needed). A draft recommended list of messages to support a data dictionary is included in Appendix B, Autonomous Mobility Appliqué Kit (AMAS) IOP Messages Working Group Recommendations.

Areas relevant to be investigated include, but are not limited to, exchange of information and control of:

• Platform information o Vehicle parameters o Towed platform information

• Diagnostics and health

• Software/hardware information

• Actuator state

• Navigation o Planning o Path representation

• Active safety modules

• Units of measure

• Behaviors

5.3.1.1.2 Message Standards under Consideration

Many of the vehicles that are desired to be augmented with an appliqué kit use the SAE J1939 message standard internally. J1939 is therefore being considered as one of the standards to be eventually profiled.

SAE JAUS has been under profiling consideration since IOP V0, and will continue to be profiled for the interface between the operator and the vehicle (i.e. the wireless connection from OCU to the applique kit).

5.3.1.1.2.1 SAE J1939 Profiling

Should SAE J1939 be adopted and subsequently profiled, the following figure shows how the IOP document structure would expand to reflect this addition. The approach to profiling SAE J1939 and custom message sets is similar to that of how SAE JAUS is profiled within the IOP.

Standard SAE J1939 is used everywhere where there is no interpretation or profiling of a specific message. In addition, custom or proprietary messages would be added to a supplemental custom messages document.

Figure 5-1: Relationship of the RAS-G IOP Profiling Documents with SAE J1939 Adoption

5.3.1.2 Additional Real-time Network Considerations

In order to facilitate safety critical interfaces that are also updatable, the IOP in the future may consider other communications interfaces, along with the ability to specify multiple redundant communication routes between the MBU and XBW as shown in the following diagram. This architecture creates flexibility in how safety critical capabilities can be updated within a program over time. This reference architecture would drive additional physical, electrical and logical interfaces to be added to the IOP in the future. The architecture itself is representative only and would not be required as an actual IOP attribute. Design and implementation is up to the designers of the system(s) within the program of record.

Some technologies for review in future versions include, but are not limited to:

• Controller Area Network (CAN)

• FlexRay

• Time-Triggered Protocol (TTP)

• Time-Triggered Ethernet (TTE)

• Low Voltage Differential Signaling (LVDS)

• Vehicle Integration for C4ISR/EW Interoperability (VICTORY)

• AutoSAR

5.3.1.3 Modeling

The Applique IOP will also consider various world modeling methods in order to facilitate semi-autonomous behaviors. The following considerations have already been identified for path planning:

• Euler path (Clothoid)

• Waypoint following

• B-spline

• Way-point following

• Steering models

5.3.1.4 SAE’s On-Road Autonomous Vehicle (ORAV) Committee

In further defining these topics, the IOP Appliqué Working Group will be participating in a Task Force for the SAE’s On-Road Autonomous Vehicle (ORAV) Committee. The primary objective will be to define the interfaces that exist between the SAK and the drive-by-wire kits (XBW).

This work overlaps the current direction of the Appliqué WG.

6 Appendix A - Discussion of Technical Topics and Lessons Learned for Future Consideration

The following sections are included to introduce technical considerations and lessons learned related to appliqué systems – as well as to propose some vehicle categorizations to aid in the further definition of appliqué system requirements in future versions of the IOP. Many of these technical concepts have been captured from the DoD’s Autonomous Mobility Appliqué System (AMAS) Joint Concept Technology Demonstrator (JCTD) and the SAE On Road Autonomous Vehicles (ORAV) committee.

Large Wheeled Vehicle Robotic Platforms Definition The Autonomous Mobility Appliqué System (AMAS) Architecture defines a semi-autonomous kit (SAK) and X-By-wire Kit (XBW). Generally, the MBU is responsible for path planning and obstacle avoidance while the XBW is responsible for actuation and active safety. This Appliqué section refers to the interface between the SAK and XBW.

MIL STD-882E defines the catastrophic hazard severity as possibly resulting in one or more of “death, permanent total disability, irreversible significant environmental impact, or monetary loss equal to or exceeding $10M.” In Tactical Wheeled Vehicles (TWV) drive-by-wire robotic systems failure in a component may lead to catastrophic effects.

TWV have enough weight and speed capability to produce a kinetic energy corresponding to a catastrophic hazard. In the current fleet, the smallest size TWV would be a HMMWV and the largest would be a HET. For example, a vehicle weighting 100 tons traveling at 65 mph (29 m/s), would produce 100x29e2/2 = 42,050 kJ of energy. In this context, we differentiate “large wheeled vehicle robotic platforms” as capable of a catastrophic hazard, as opposed to “small wheeled vehicle robotic platforms.”

Large Wheeled Vehicle Robotic Platforms Assumptions The acceptable catastrophic hazard would be “improbable,” which is defined in MIL STD-882E as “so unlikely, it can be assumed occurrence may not be experienced, with a probability of occurrence less than 10-6 in that life.” Considering TWVs system life is expected to be between 1,000 and 10,000 hours of operation, this requirement would be equivalent with industry standard IEC 61508 Safety Integrity Level (SIL) 4, which requires the system to tolerate a single failure and encounter a safety critical failure with probability not exceeding 10-9 per hour.

The large wheeled vehicle robotic platform can be manned (where the final responsibility is assumed by the human driver), or unmanned. An unmanned system could function as optionally manned, but from a safety perspective it must be built assuming the unmanned technology is responsible for the safety critical decision making and control of the vehicle.

We assume that there is no fail-safe state for a large unmanned automated vehicle system traveling at high speeds. For this case, vehicles taking tens of seconds to stop need to maintain steering control and obstacle avoidance abilities. Many circumstances exist where harsh braking can have catastrophic results, especially when trailers are involved. When a sub-system has a fault that could result in a catastrophic system failure, the fault must be detected and the system must retain control of the vehicle until it can be brought to a controlled stop. These systems need to be fail-operational and tolerant of at least 1 single point failure.

With the above assumption we derive the following definitions. Considering a large wheeled vehicle robotic platform cruising at velocity V, we define the buffer distance DB that will ensure safety around the platform or for the platform coming across an obstacle and initiating braking as:

Where TR is the Reaction Time of the decision maker on the platform, which can be a human operator or an unmanned system; DS is the Platform Stopping Distance at Velocity V; and FS is a Safety Factor with values in the interval (0, 1]. DB can be lowered at the expense of safety, represented here by FS. Outside the buffer distance, a unity safety factor would guarantee 100% safety.

Since kinetic energy increases with the square of the speed, and in general mass contributes little to the stopping distance, large wheeled vehicle robotic platforms can be classified respect to their speed capabilities around a “critical speed” derived from the above formula:

Furthermore, when the vehicle operates around people, speed is a good characterization factor when allowing people to get out of the way in case the vehicle approaches them. A good rule of thumb derived from best practices suggests about 25 kph speed as a limiting factor for vehicles operating around people, and this can be verified with the above formula as follows. Considering a predefined buffer distance DB of 30 meters, a unity safety factor (100%), 1 second reaction time, and a value for the coefficient of static friction between poor tires and a road surface of 0.4, the critical speed is calculated to be about 25 kph (about 15 mph). The stopping distance was calculated using the formula:

-where V is speed, 𝜇𝜇 is the friction coefficient and g is the gravitational acceleration.

Large Wheeled Vehicle Robotic Platforms - Categories Definition Having estimated this critical speed, we can define now three categories of large wheeled vehicle robotic platforms as follows.

Category I:

𝐷𝐷𝐵𝐵 = [(𝑉𝑉 ∙ 𝑇𝑇𝑅𝑅) + 𝐷𝐷𝑆𝑆] ∙ 𝐹𝐹𝑆𝑆

𝐷𝐷𝐷𝐷 =

𝑉𝑉2

2𝜇𝜇𝜇𝜇

𝑉𝑉𝑉𝑉 =

𝐷𝐷𝐵𝐵

𝐹𝐹𝑆𝑆� − 𝐷𝐷𝑆𝑆

𝑇𝑇𝑅𝑅

Large wheeled vehicle robotic platforms in Category I could be manned or unmanned.

They operate at low speed (< Vc), away from people with enough buffer (DB) to allow the vehicle to be safely stopped. Applying the brakes to bring the vehicle to a safe stop is considered sufficient as drive-by-wire failsafe action. Only the XBW is required to be fail safe, to ensure the vehicle can be brought to a stop when a sub-system has a fault.

Category II:

Large wheeled vehicle robotic platforms in Category II are manned, i.e. although the system is capable of different levels of automated driving, the human operator has the final responsibility for safety. The vehicle can operate at speeds greater than the critical speed (>= Vc ) or they operate near people (inside the buffer distance). In case of a fault it needs to operate safely, including avoiding dynamical obstacles, until the human operator takes over or until the vehicle stops. The planned path needs to be passed from the SAK to the XBW at a certain rate, so that the XBW can execute the last path to bring the vehicle to a safe stop in case the SAK is disabled. Therefore significant portions of the XBW may be required to be fault-tolerant.

Category III:

Large wheeled vehicle robotic platforms in Category III are designed to be unmanned, which does not preclude the capability for manned operations as in Category II (optionally manned). The vehicle can operate at speeds greater than the critical speed (>= Vc ) or they operate near people (inside the buffer distance). In case of a fault it needs to operate safely, including avoiding dynamical obstacles, until the vehicle stops in an area considered to be safe. If the vehicle is on a highway it needs to be able to stop in one of the predefined safe harbor areas. Considering this category of platforms can be remote assets, a fault should not preclude the system to complete its mission;

therefore they have to be safety-critical as well as mission critical. As such, the XBW, the interface between the SAK and XBW, and the SAK each need to be fault-tolerant.

Fault-Tolerant Data-Bus Requirements Category III requires fault-tolerant data-bus interfaces, thus able to maintain functionality throughout a single failure. We can further analyze the single point of failure for data buses, to derive the requirements for a fault-tolerant data-bus.

The common bus failures and their respective mitigations/requirements are summarized in the following table:

Bus Failure Attribute Mitigation/Requirement

Latency, Jitter, Clock drift Temporal Determinism Time Triggered Architecture, Clock Synchronization

Value Failure, Bus Failure, Node Failure

Replica Determinism Fail-Silence, Redundant Data Bus, Redundant Node

Babbling Idiot Babbling Idiot Bus Guardian

Short-Circuit Short-Circuit Active Star

7 Appendix B:

Autonomous Mobility Appliqué System

(AMAS) IOP

Messages Working Group Recommendations

2/20/2015 Recommended Messages to Support XBW & SAK

Report generated from the AMAS IOP Messages Group activities in defining a communication interface between the X-By-Wire Kit (XBW) and the Semi-Autonomous Kit (SAK).

Reference herein to any specific commercial company or public/private institution, product, process or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the Department of the Army. The opinions of the authors expressed herein do not necessarily state or reflect those of the United States Government or the DoA, and shall not be used for advertising or product endorsement purposes.

Recommended Messages to Support XBW & SAK Interface

Recommended Messages to Support XBW & SA

1 Background The current and future US Armed Forces face an operational environment based on uncertainty, anti access and aerial denial threat tactics. Currently, the leading causes of casualties within South West Asia (SWA) are due to IEDs, followed by vehicle accidents, and then direct combat.

Operations are limited because of weather conditions and other environmental factors that limit visibility. The IED mitigation solutions integrated onto most military vehicles have limited the mobility of the vehicles and the visibility of the operators. All tactical vehicles are key targets for the enemy when traveling within the enemy Area of Operations (AO). These threats and limitations burden the operators and passengers with additional requirements and hamper situational awareness.

The Autonomous Mobility Applique System (AMAS) program aims to alleviate this additional burden and provide greater situational awareness through the automation of driving through the integration of robotic technology. AMAS will provide field commanders with a powerful and flexible tool by providing additional options in the deployment of assets and reduce the impact of expected force structure reductions.

AMAS is intended to implement its solution through the development of a “Solution Set.” A Solution Set consists of two (2) primary kits; an SAK and a XBW. The XBW will be unique to the targeted platform and provide the interfaces for the SAK. The SAK will contain the sensing and intelligence to deploy various levels of autonomy.

The AMAS IOP Messages Group, led by the University of Michigan-Dearborn Connected Vehicle Center (UMD-CVPC), conducted weekly discussions over a two year period with experts in both industry and government. The objective of this activity was to define and design a common system Architecture for the AMAS, based on standard interfaces and open standards. To accomplish this, the UMD-CVPC conducted trade studies, interoperability experimentation, and system engineering analysis, using Government furnished information, to assess various software and hardware solutions as explored by the IOP group.

2 Activity Goals The goal for this activity was to assist in the development of an interoperability standard in form of a message list with the necessary documentation to support the AMAS architecture with consideration of the following:

• The SAK shall implement an interoperable interface to the XBW across all JCTD vehicle platforms without requiring additional SAK calibration.

• The interoperable interface shall allow the SAK to access the vehicle platform environment, for sensing and control, as required by the specific capabilities of the SAK.

• Design factors of interest for the SAK include: affordability; open architecture and in some cases open source code; commonality of: functionalities, software modules, standard interfaces, and COTS components across different platforms; and ease of integration.

3 Assumptions The work completed by the AMAS IOP Messages Group was made with the following assumptions:

• Performance of the AMAS systems as described by the Autonomous Convoy Operations (ACO) Capability Development Document (CDD) Draft v 2.1, dated 26 August, 2014 and RPP W15QKN-08-9-001-Rpp17, dated March 2012;

• SAK and XBW interface investigation only;

• DARPA Urban Challenge “BOSS” autonomous vehicle architecture as baseline architecture;

• AUTOSAR for Vehicle Control Module (VCM) to vehicle communication;

• VICTORY v 1.6.1, dated June 30, 2014 for vehicle UI;

• Dedicated communication bus for VCM sensor data;

• Safety criticality – very high duration (1B hours) between critical failures;

• Trailers by-wire included;

• Raw camera data and other sensor data from XBW shared with SAK; and

• SAK does not override XBW when installed.

3.1 XBW Specific Assumptions

3.1.1 Configuration

We assumed the installation of additional hardware and software necessary to provide Active Safety Capability and interface/control of the steering, braking, transmission, and engine functions of the vehicle. XBW will be interfaced electronically and not interfere with the egress/ingress of the operator.

3.1.2 Problems Addressed

The XBW will prevent accidents through rollover and yaw stability (Over/Under steer) control, collision warning and mitigation, emergency brake, lane keeping; reduce fatigue through Adaptive Cruise Control (ACC); provide Interface to control the vehicle which would provide for future upgrades of robotic technology as needed.

3.1.3 Advantages

The following advantages of the XBW were assumed by the incorporation of Collision Mitigation, Stability Control, Emergency Braking, Adaptive Cruise Control, Roadway Departure Prevention:

• 26% to 59% Reduction in Truck Related Accidents1

• Improved Handling due to Stability Control

• Decrease in Physical Load on Operator

3.2 SAK Specific Assumptions

3.2.1 Configuration

We assumed the SAK interfaces with the XBW and provides leader/follower, waypoint navigation, and obstacle detection/avoidance features to implement a convoy capability that can be operated in a manned or unmanned mode.

3.2.2 Problems Addressed

With the installation of the SAK, we assume that lives will be saved via an increase in combat power and situational awareness through semi-autonomous convoy operations; reduce accidents through obstacle detection/avoidance, road keeping (unpaved), and night vision enhancement; save fuel in convoy operations;

3.2.3 Advantages

The following advantages of the SAK were assumed:

• increased night ops and op tempo;

• when driving is automated, the operator can manually override;

• decreased mental load on operator;

• increased situational awareness due to driving cognitive load reduction;

• further decrease in physical load on operator;

• force Multiplier - ability to decrease manning in vehicles;

• when in unmanned mode, every other vehicle in convoy is unmanned;

4 Approach The AMAS IOP Message Group completed three major iterations of message generation and analysis. The first iteration was a brainstorming process of creating a data dictionary of applicable messages. The second iteration involved creating a high level reference architecture and exploring how message could be mapped to this architecture and identifying gaps in the message list. Figure 1 shows the high level architecture and Figure 2 shows the architecture divided into modules. The third iteration explored the assumptions made given the proposed architecture and identified the necessary messages to support the assumptions.

Figure 1. High Level Reference Architecture

Figure 2. Modular Reference Architecture

5 Proposed Messages The messages identified by the AMAS IOP Message Group are detailed below.

5.1 Vehicle Parameters

Message Name Short Description Vehicle type Vehicle types are predefined vehicle parameter groups that may have several vehicle information values already defined.

Vehicle reference frame The vehicle reference frame is located at the center of the rear axle or tandem axle. Origin for Z is on the ground.

Minimum turning radius The minimum radius the vehicle can turn in either left or right directions [m].

Maximum longitudinal acceleration Query value for maximum longitudinal acceleration. The maximum capable longitudinal acceleration for the vehicle at curb weight [m/s^2].

Maximum longitudinal deceleration The maximum capable longitudinal deceleration for the vehicle at curb weight [m/s^2].

Maximum lateral acceleration The maximum capable lateral acceleration for the vehicle at curb weight [m/s^2].

Minimum forward longitudinal velocity The minimum controllable forward longitudinal velocity for the vehicle at curb weight [m/s].

Maximum forward longitudinal velocity

The maximum capable forward longitudinal velocity for the vehicle at curb weight [m/s].

Minimum reverse longitudinal velocity The minimum controllable reverse longitudinal velocity for the vehicle at curb weight [m/s].

Maximum reverse longitudinal velocity The maximum capable reverse longitudinal velocity for the vehicle at curb weight [m/s].

Maximum steering curvature change rate

The maximum steering curvature change rate for the vehicle [1/m*s].

Maximum steering wheel angle left The maximum steering wheel angle left [deg].

Maximum steering wheel angle right The maximum steering wheel angle right [deg].

Maximum steering curvature left The maximum steering angle to the left for the vehicle [1/m].

Maximum steering curvature right The maximum steering angle to the right for the vehicle [1/m].

Wheelbase The wheelbase is the measurement between the center of the front and center of tandem on same side of the vehicle [m].

Track width The distance between the tire centers for an axle [m]. May be defined for each axle on the vehicle.

Nominal ground clearance The amount of space between the base of the vehicle tire and the underside of the chassis at curb weight [m].

Length The overall vehicle length measured from forward most point of vehicle to rearward most point of vehicle [m].

Width The overall vehicle width measured from the outer most protruding fixture on the left and right sides [m].

Length to forward most point of vehicle

The distance from the origin in the vehicle reference frame of the vehicle to the outer surface of the forward most point of the vehicle [m].

Length to rearward most point of vehicle

The distance from the origin in the vehicle reference frame of the vehicle to the outer surface of the rearward most point of the vehicle [m].

Number of axles The number of axles on the vehicle [ - ].

Center of gravity (x,y,z) The center of gravity of the vehicle at curb weight measured from the origin in the vehicle reference frame (x,y,z) [m],[m],[m].

Vehicle mass The mass of the vehicle at curb weight [kg].

Payload mass The mass of the payload on the vehicle [kg].

Payload overhang length The length of the payload that overhangs from the vehicle [m].

Adding the vehicle length and the payload overhang length will give the total length of the vehicle.

Payload overhang width The width of the payload that overhangs from the vehicle [m].

Adding the vehicle width and the payload overhand width will give tht total width of the vehicle.

Query payload overhang height Query payload overhang height.

Payload center of gravity (x,y,z) The center of gravity of the payload measured from the origin in the vehicle reference frame (x,y,z) [m], [m], [m].

Minimum braking distance The minimum braking distance to bring the vehicle to a complete stop from an initial longitudinal velocity of 80 kph at curb wieght [m].

Adjusted ground clearance delta The change in ground clearance due to pressure delta w.r.t cross country setting and other conditions [m].

Tire pressure status The tire pressure status for a specific axle. (low, normal, over inflated) [ - ].

Clearance height The overall vehicle height measured from the top of the vehicle to the ground for clearance purposes [m].

Approach angle The maximum angle (from the ground) that a hill or obstacle can have and that the front of the vehicle can still clear [deg].

Departure angle Query departure angle. The maximum angle (from the ground) that a hill or obstacle can have and that the rear of the [deg] vehicle can still clear [deg].

Break-over angle The angle between the vehicle's tires and the middle of its underside [deg].

5.2 Trailer Parameters

Message Name Short Description Trailer status Specifies if a trailer is attached to the vehicle [ - ].

Trailer type The type of trailer.

Trailer reference frame Located at the center of the rear axle or tandem axle.

Trailer wheelbase The wheelbase is the measurement from the front of the trailer and the center of the axle or tandem axle. Standard ISO 11992 Geometric Data [m].

Trailer track width The distance between the tire centers for an axle [m]. May be defined for each axle on the trailer.

Trailer nominal ground clearance The the amount of space between the base of the trailer tire and the underside of the trailer at curb weight [m].

Adjusted ground clearance delta The change in ground clearance due to pressure delta w.r.t cross country setting and other conditions [m].

Trailer height The overall trailer height measured from the top of the vehicle to the ground for clearance purposes [m].

Trailer length The length is measured from the trailer origin to the most rearward surface [m].

Trailer width The overall trailer width measured from the outer most protruding fixture on the left and right sides [m].

Trailer number of axles Number of ales on trailer [ - ].

Trailer center of gravity (x,y,z) The center of gravity of the trailer at curb weight measured from the origin in the trailer reference frame (x,y,z) [m], [m], [m].

Trailer approach angle The maximum angle (from the ground) that a hill or obstacle can have and that the front of the trailer can still clear [deg].

Trailer departure angle The maximum angle (from the ground) that a hill or obstacle can have and that the rear of the trailer can still clear [deg].

Trailer break-over angle The angle between the trailer's tires and the middle of its underside [deg].

Trailer unloaded mass The mass of the trailer without payload [kg].

Trailer payload center of gravity (x,y,z) The center of gravity of the payload measured from the origin in the trailer reference frame (x,y,z) [m], [m], [m].

Trailer payload overhang length Trailer payload overhang length [m].

Trailer payload overhang width Trailer payload overhang width [m].

Trailer payload overhang height Trailer payload overhang height [m].

Trailer payload mass Trailer payload mass [kg].

5.3 Trailer Hitch Parameters

Coupling point location for trailer (x,y,z)

The hitch ball mount location measured from the origin of the trailer reference frame (x,y,z) [m], [m], [m].

Coupling point location for vehicle (x,y,z)

The coupling point location measured from the origin of the vehicle reference frame (x,y,z) [m], [m], [m].

5.4 Software & Hardware Info

SAK software version number SAK software version number.

SAK hardware version number SAK hardware version number.

SAK manufacturer code SAK manufacturer code.

SAK hardware manufactured date SAK hardware manufactured date.

SAK IOP version number SAK IOP version number.

SAK software flash date SAK software flash date.

XBW software version number XBW software version number.

XBW hardware version number XBW hardware version number.

XBW manufacturer code XBW manufacturer code.

XBW hardware manufactured date XBW hardware manufactured date.

XBW IOP version number XBW IOP version number.

XBW software flash date XBW software flash date.

5.5 Actuator State

Message Name Short Description Transmission current gear The gear currently engaged in the transmission or the last gear engaged while the transmission is in the process of shifting to the new or selected gear [ - ].

Steering wheel angle The main operator`s steering wheel angle (on the steering column, not the actual wheel angle) [deg].

Brake application pressure Gage pressure of compressed air or fluid in vehicle braking system measured at the brake chamber when brake shoe (or pad) is placed against brake drum (or disc) [kPa].

Brake primary pressure Gage pressure of air in the primary, or supply side, of the air brake system [kPa].

Brake secondary pressure Gage pressure of air in the secondary, or service side, of the air brake system [kPa].

Report brake secondary pressure Report value for brake secondary pressure [kPa].

Steering wheel torque Steering wheel torque [Nm].

Trailer hitch angle. Trailer hitch angle [deg].

Tire mode. Tire mode (CTIS) [ - ].

Steering wheel angle rate Steering wheel angle rate [deg/s].

Steering actuator torque Steering actuator torque [Nm].

Steering actuator position Steering actuator position [m].

Steering actuator rate Steering actuator rate [m/s].

Rain sensor status Rain sensor status.

Brake pedal pressure Brake pedal pressure.

Parking brake Switch signal which indicates when the parking brake is set.

Set parking brake Set value for parking brake actuation [ - ]. Command signal to influence the pneumatic pressure in the circuit or reservoir for the parking brake and/or the trailer supply.

Wiper fluid level Wiper fluid level [ - ]. Values: low, not low

Accelerator pedal position Accelerator pedal position. The ratio of actual position of the analog engine speed/torque request input device to the maximum position of the input device.

Engine desired throttle valve position Engine desired throttle valve position. The desired position of the Throttle valve.

5.6 Navigation Data

Longitudinal acceleration Longitudinal acceleration. Indicates the longitudinal acceleration of the vehicle [m/s^2].

Lateral acceleration Indicates a lateral acceleration of the vehicle (the component of vehicle acceleration vector along the Y-axis) [m/s^2].

Wheel-based vehicle speed Speed of the vehicle as calculated from wheel or tailshaft speed [m/s].

Yaw rate Indicates the rate of rotation about the vertical axis (i.e. the z-axis) [deg/s].

Wheel speeds High resolution measurement of the speed of the wheels [m/s].

Roll angle The angle between the vehicle y-axis and the ground plane (i.e.

rotation about the X-axis) [deg].

Roll rate Query value for roll rate. Roll rate is the rate-of-change of the roll angle over time [deg/s].

Pitch angle Pitch (rotation about the y-axis) of the vehicle as calculated by the navigation device(s) [deg].

Pitch rate Pitch rate is the rate-of-change of the pitch angle over time, where the pitch angle vector is in the direction of travel of the vehicle [deg/s].

5.7 Advanced Emergency Braking System

Advanced emergency braking system (AEBS) state

Current operational state of advanced emergency braking system.

Collision warning level To implement different HMI (human machine interface) concepts, e.g. visual only, visual/audible, different warning tones etc., the AEBS provides different levels of collision warning.

Relevant object detected for AEBS Indication if the AEBS is monitoring a relevant object.

Bend off probability of relevant object Probability if monitored relevant object might start a turning maneuver, which could clear the travelling path of the host vehicle.

Time to collision with relevant object The time to collision is the duration after which the predicted travelling paths of host vehicle and relevant object lead to a distance of 0m between both.

5.8 Military Lighting Command

Rear black out marker select Rear black out marker select.

Front black out marker lamp select Front black out marker lamp select.

Convoy lamp select Convoy lamp select.

Convoy driving lamp select Convoy driving lamp select.

Black out brake/stop lamp select Black out brake/stop lamp select.

Night vision illuminator select Night vision illuminator select.

Black out work lamp select Black out work lamp select.

Black out intensity selection Operators black out intensity selection.

5.9 Vehicle Path

Vehicle drive mode Set value for vehicle drive mode. Three types of drive mode:

direct control, waypoint, clothoid, and spline.

Set steering wheel request Set value for steering request. Parameters [max torque, swa, max swa rate, swa control flag].

Set Steering Curvature Set Steering Curvature [1/m] Set speed request Set value for speed request [speed, max acceleration] [km/h].

Set transmission gear request Set value for transmission gear request [gear range, gear]. Gear requested by the operator, ABS, or engine.

Query clothoids Query value for clothoids.

Report clothoids Report value for clothoids.

Set clothoids Set values for clothoids [ - ].

Set spline Set values for splines [ - ].

5.10 Secondary Controls

Set turn signal Set value for turn signal.

Set hazard lights Set value for hazard lights.

Set high/low beam Set value for high/low beam.

Set reverse lights Set value for reverse lights.

Set brake lights Set value for brake lights.

Set horn state Set value for horn state.

Set wiper Set value for wiper.

Set front sensor cleaning fluid Set value for front sensor wiper fluid.

Set rear sensor cleaning fluid Set value for rear sensor wiper fluid.

Set door lock/unlock Set value for door lock/unlock.

Set start/stop engine Set value for start/stop engine.

5.11 Health Status

SAK heartbeat Report value for SAK heartbeat.

XBW heartbeat Report value for XBW heartbeat.

SAK health status Report value for SAK health status.

XBW health status Report value for XBW health status.

5.12 Battery

Battery status Report value for battery status.

Battery charge level Report value for battery charge level.

5.13 Active Safety Modules

Yaw stability control status Report value for yaw stability control status.

Roll stability control status Report value for roll stability control status.

ABS status Report value for ABS status.

Road surface friction detection status Report value for road surface friction…