Remote Autonomous Vehicle - System Architecture

Peter Henderson

25 June 2010

Copies of this generated document are available at http://pmhs.co.uk/RAV

The system described in this document is a Remote Autonomous Vehicle (RAV), which is intended to operate both autonomously and in collaboration with other RAVs when organised into collaborating Groups (see http://pmhs.co.uk/RAVSoS). The internal structure of an individual RAV is the subject this document. Individual RAVs can be instructed to carry out tasks, which they will do autonomously. Individual RAVs are capable of reaching a destination autonomously, avoiding collisions and other obstacles. Instructions are relayed to individual RAVs from Ground Control.

This system description is based on the WAVE m3 metamodel. Consequently it contains details of the major components and their interfaces. The level of abstraction used here is that considered appropriate to a system architect who presents their proposal in a rigorous and clearly argued form but one which can be comprehended by a generalist in a few hours.

The emphasis on components and interfaces is because this is an Open Architecture in the sense that it contains sufficient information that conforming components can be procured from independent suppliers who have obeyed the rules of the Open Interfaces. The descriptions of individual components is therefore rather generic, having to effectively describe a family of procurable instances which will vary in their detailed implementations. For example, the angle through which a particular RAV assembly can reliably turn (or rather, the tolerance on that angle) may vary from supplier to supplier.

It is the variations in capability of components that enable the cost-effective evolution of the RAV, through-life. This is the principal benefit of Open Systems.

Copies of this generated description are available at http://pmhs.co.uk/RAV. The organisation of RAVs into collaborating Groups is described in a separate document. This is available at http://pmhs.co.uk/RAVSoS.


1 RAV

This is the description of Component RAV. The assumption here is that the RAV is a wheeled ground vehicle that can work in unpopulated regions such as a moon or a planet. The assumption is that communication with the RAV is intermittent and may have a large latency. Hence the vehicle is expected to operate autonomously, performing tasks according to a script relayed to it from Ground Control.

The basic behaviour of the RAV is to carry out complex instructions autonomously and in collaboration with other RAVs. On its own, the RAV can make its way to specified destinations and carry out tasks for which it has been equipped (such as mapping). On its own, the RAV can avoid collisions and avoid obstacles, finding a sensible route to its destination. In collaboration with other RAVs, it can carry out more complex tasks (such a mapping a very large area). These collaborative tasks are enabled by direct communication between RAVs. A RAV will be instructed to join a Group for the purposes of collaborative tasks. A RAV may be a member of more than one Group (or a member of none).

An individual RAV will receive instructions from GroundControl over the interface Interface-GC-RAV. As a member of a Group, a RAV may also receive instructions from GroundControl over the interface Interface-GC-Group. In practice, GroundControl will interact only with a subset of the members of a Group and rely upon these members to share the information with other members of the Group. The reliabilty of the Group to complete a given task is dependent on the effectiveness of this sharing of information implemented by the RAV.

The RAV supplies interfaces that allow it to communicate with Ground Control and with other RAVs. All messages between Ground Control and the RAV are requests from Ground Control. That is, only solicited information is communicated to Ground Control. We describe this by saying that the initiative to communicate is taken by Ground Control. The initiative to communicate with another RAV is taken by the RAV. This message will be of the form "Here is some data, let me know if you have received it". In order that this RAV can initiate a communication, it requires access to the RAV-RAV interface of the other RAV.

The RAV is conrolled by the Manager module qv. It's overall behaviour is as follows. It can move to a new location by giving instructions to the Power-Drive module qv, telling the vehicle to move forward and to the Steering Module qv telling the vehicle to change direction. It can determine its position using the Location-Sensor qv and detect obstacles (walls, steep inclines etc.) using the Obstacle-Sensor qv. The sensitivity of the sensors and of the stepping and turning will vary from RAV to RAV, according to which generation it is. These variations are effected by generations of evolving components, supplied by independent suppliers according to the Open Architecture described here.

CONTAINS Comms (qv) ; Manager (qv) ; Obstacle-Sensor (qv) ; Location-Sensor (qv) ; Power-Drive (qv) ; Steering (qv) ;

REQUIRES Interface-RAV-RAV (qv) ;

SUPPLIES Interface-GC-RAV (qv) ; Interface-GC-Group (qv) ; Interface-RAV-RAV (qv) ;

IMPLEMENTS RAV-Requirement-SharesDataFrequently (qv) ; RAV-Requirement-SeeksFullKnowledge (qv) ;


2 Comms

The Comms module operates to relay information between Ground Control and the RAV, and between RAVs. It is autonomous in the sense that it buffers data and operates a protocol that ensures reliable two-way communication. It uses positive acknowledgement and retry to guarantee reception and delivery of messages. It also implements the Secure Conversation security protocol.

The Comms module will receive data from GC or from another RAV and retain it until the Manager asks for it. It will receive data from the Manager for transmission to GC or to another RAV and take full responsibility for its reliable and secure transfer.

IS CONTAINED IN RAV (qv) ;

REQUIRES Interface-RAV-RAV (qv) ;

SUPPLIES Interface-GC-RAV (qv) ; Interface-GC-Group (qv) ; Interface-RAV-RAV (qv) ; Interface-Comms-Mgr ;


3 Manager

The Manager is the most complex module, in terms of its behaviour. It is anticipated that the Manager will exist in many versions, supplied by different suppliers, each with their own refined versions of the behaviour described below.

On receipt os an instruction to proceed to a specified location the manager calculates a heading. It then uses the Power-Drive module to begin moving forward. If an obstacle is detected, the manager uses the Steering module to set a new heading and move around (or past) the obstacle. By periodically correcting its heading according to algorithms which are specific to individual suppliers, the Manager will ensure that the vehicle reaches its destination. If the destination is unreachable, Manager will report that.

This is the module which is expected to show the most innovation, thus enouraging competition between suppliers. It is important that this module can be upgraded reliably and quickly at a distance. The Manager module must thus be able to install a new version and hand over control to that replacement. Equivalently the Manager module mus be able to accept a stand-down instruction, which returns control to a previous version, if the upgrade proves to have problems.

IS CONTAINED IN RAV (qv) ;

REQUIRES Interface-Comms-Mgr ; Interface-L-Mgr (qv) ; Interface-B-Mgr (qv) ; Interface-P-Mgr (qv) ; Interface-S-Mgr (qv) ;


4 Location-Sensor

By various optical or electronic means (specific to suppliers) the Location-Sensor module can answer queries of the form "Where am I?". Location (on a remote planet) is specific to design of the Manager module and will an openly published detail of that module. Note that the sensor may be active, in the sense that it is always taking readings and thus able to give an immediate (TBD) response, but it does not take the initiative to inform the Manager. Rather it waits for the query. This is an architectural decision intended to simplify the open interfaces between the components of the RAV, so that a large variety of supply is created in order to maximise innovation.

IS CONTAINED IN RAV (qv) ;

SUPPLIES Interface-L-Mgr (qv) ;


5 Obstacle-Sensor

By various optical, electronic and physical means (specific to suppliers) the Obstacle-Sensor module can answer queries of the form "How far ahead of me is clear?". Note that the sensor may be active, in the sense that it is always taking readings and thus able to give an immediate (TBD) response, but it does not take the initiative to inform the Manager. Rather it waits for the query. This is an architectural decision intended to simplify the open interfaces between the components of the RAV, so that a large variety of supply is created in order to maximise innovation.

IS CONTAINED IN RAV (qv) ;

SUPPLIES Interface-B-Mgr (qv) ;


6 Power-Drive

The vehicle is only required to move forward. The Power-Drive module accepts instructions of the form "Move ahead 10cm", for distances that are specific to different suppliers but are normally in a range (1cm -1m). Actual movement of the vehicle will be approximate within a specified tolerance TBD. It will not be sufficiently accurate that inertial guidance can be used.

IS CONTAINED IN RAV (qv) ;

SUPPLIES Interface-P-Mgr (qv) ;


7 Steering

The vehicle is required to be able to turn within its own space. This turning is achieved by different means according to the mechanical construction of the wheels/tracks and the transmission. The Steering module will accept instructions of the form "Turn clockwise/anticlockwise 10 degrees, for angles that are specific to different suppliers but are normally in a range (5 degrees to 180 degrees). Actual movement of the vehicle will be approximate within a specified tolerance TBD. It will not be sufficiently accurate that inertial guidance can be used.

IS CONTAINED IN RAV (qv) ;

SUPPLIES Interface-S-Mgr (qv) ;


8 Interface-L-Mgr

This is the interface supplied by the Location-Sensor. The Location-Sensor module can answer queries of the form "Where am I?". All messages to this module are queries (i.e. request-reply). That is the caller always takes the initiative and expects a reply, even if that is just an acknowledgement.

IS REQUIRED BY Manager (qv) ;

IS SUPPLIED BY Location-Sensor (qv) ;


9 Interface-B-Mgr

This is the interface supplied by the Obstacle-Sensor. The Obstacle-Sensor module can answer queries of the form "How far ahead is clear?". All messages to this module are queries (i.e. request-reply). That is the caller always takes the initiative and expects a reply, even if that is just an acknowledgement.

IS REQUIRED BY Manager (qv) ;

IS SUPPLIED BY Obstacle-Sensor (qv) ;


10 Interface-P-Mgr

This is the interface supplied by the Power-Drive. The Power-Drive module accepts queries of the form "Move forward 10cm", for distances that are specific to individual suppliers but are within a specified range and tolerance (TBD). All messages to this module are queries (i.e. request-reply). That is the caller always takes the initiative and expects a reply, even if that is just an acknowledgement.

IS REQUIRED BY Manager (qv) ;

IS SUPPLIED BY Power-Drive (qv) ;


11 Interface-S-Mgr

This is the interface supplied by the Steering module. The Steering module accepts queries of the form "Turn 10 degreees clockwise", for angles that are specific to individual suppliers but are within a specified range and tolerance (TBD). All messages to this module are queries (i.e. request-reply). That is the caller always takes the initiative and expects a reply, even if that is just an acknowledgement.

IS REQUIRED BY Manager (qv) ;

IS SUPPLIED BY Steering (qv) ;


12 Interface-GC-Group

This is the description of Interface-GC-Group.

Entities that supply this interface must be able to interpret messages intended for Groups of which they are members. Such messages include task descriptions which are documents understood by individual RAVs. Tasks may be specialised to RAVs of particular types, such as those equipped with particular instruments.

A typical task description message (which is an XML document) might tell a Group to go to a particular location and to survey a particular area. On receiving such a message over this interface, or over a RAV-RAV interface, each individual RAV will then transmit the message to other members of the Group. Established message sharing algorithms ensure that this information reaches all connected RAVs, is not duplicated and that eventually all members of the Group know which other members have received it.

Other messages from Ground Control to Groups include housekeeping messages (e.g. bulk data requests, software upgrades) but in general such requests are sent to individual RAVs for security reasons.

IS SUPPLIED BY RAV (qv) ; Comms (qv) ;


13 Interface-GC-RAV

This is the description of Interface-GC-RAV.

An individual RAV will receive instructions from GroundControl over the interface Interface-GC-RAV. As a member of a Group, a RAV may also receive instructions from GroundControl over the interface Interface-GC-Group.

This interface must be able to interpret messages directed to individual RAVs from Ground Control. Such messages include descriptions of individual tasks to perform but also instructions to join or leave a particular Group. Some security configuration is established by communications directly with Ground Control.

Task descriptions are XML documents in a format defined elswhere, but generally include commands of the form "Go to location X and collect data on Y" or "Join Group Z and engage in the tasks that the Group has been given".

IS SUPPLIED BY RAV (qv) ; Comms (qv) ;


14 Interface-RAV-RAV

This is the description of Interface-RAV-RAV.

RAVs communicate with each other for the purposes of collaborating on a task and for reliability. When required to do something, as a member of a Group, a RAV will share that request with other members of that Group in a timely manner. As a matter of course a RAV will copy data it has collected to other RAVs in the same Group to ensure that that data has the greatest chance of reaching Ground Control when it is requested. So for example, a Group that is surveying an area will each have a fairly complete picture of the survey to date, at any time. Ground Control can request that data from any member, or indeed from many members, and use these almost complete descriptions to form a more complete and more consistent picture.

All communication is secured by a variant of Secure Conversation, so that only participants allowed to know information will be able to interpret what they are given. They may of course pass it on. Secure Conversation guarantees the integrity and authenticity of a message as well as its confidentiality.

For example, a RAV may publish its survey data to other Group members,encrypted only for integrity and authenticity, so that they can read the data and use it for their own decision making (such as which subareas to concentrate on themselves). However, if a RAV has confidential data to communicate and hasn't been asked for this by Ground Control, it can communicate it to other RAVs for relay to Ground Contol, should they be asked, encrypting this message so that the relaying intermediary cannot read it or tamper with it.

IS REQUIRED BY RAV (qv) ; Comms (qv) ;

IS SUPPLIED BY RAV (qv) ; Comms (qv) ;


15 RAV-Requirement-SharesDataFrequently

This is the description of RAV-Requirement-SharesDataFrequently. In anticipation of its own failure a RAV will make its data publicly available to other RAVs in this Group.

IS IMPLEMENTED BY RAV (qv) ;


16 RAV-Requirement-SeeksFullKnowledge

This is the description of RAV-Requirement-SeeksFullKnowledge. In anticipation of others failure a RAV will seek to copy data from other RAVs to make a complete picture for itself. Where data is not forthcoming a RAV will seek to complete its knowledge autonomously.

IS IMPLEMENTED BY RAV (qv) ;