You are on page 1of 8

ARCHITECTURE FOR AN AUTONOMOUS REClONFIGUREABLE

INTELLIGENT CONTROL SYSTEM (ARICS)

Arie Yavnai

RAFAEL, P.O.Box 2250 ( # 39 ) , Haifa 3102!1, ISRAEL

Tel : + 972 - 4 - 990 - 8645 Fax : + 972 - 4 - 990 - 8055


Abstract

ARICS is an embedded Autonomous Mission the above mentioned approaches and on the
Controller (AMC) , designed to be used onboard associated architectures , can be found elsewhere
highly Autonomous Vehicles (AV). It is designed in the relevant literature.
to meet the requirements for extended autonomous
capabilities. Such capabilities are required by long ANCSs architecture is hybrid. This architecture
range ,long endurance AVs, such as Autonomous was chosen because it combines the characteristics
Underwater Vehicles - AUVs. Although the of both reasoning-driven model-based functional
architecture is kept as generic and common as hierarchy , as well as the characteristics of
possible , the specific Functional Processing reactive-reflexive behavior hierarchy , while
Modules (FPMs) may be different for various avoiding their inherent weaknesses. Hybrid
vehicles and applications . ARICS is designed to architecture supports both the advantages of
provide the AUV with the following onboard , real reasoning-driven model-based functional
time , self-contained capabilities : a) Goal-directed hierarchy, e.g., goal-directed planning , model-
and event-driven reactive mission and system based prediction , assimilation of multiple data
management ; b) Plan updating , adjusting , or sources ,and flexible handling of complex
replanning ; c) Complete in-mission, on-the-move , behaviors, as well as the advantages of reactive-
planning ; d) Context-sensitive and event-driven reflexive behavior hierarchy, e.g., good
exception handling ; e) Fault management,error responsiveness, robustness and modularity.
recovery,and module/functionality reconfiguration
; f) Coordinating the AUVs cooperative operation From engineering point of view, it is our opinion
with other AUVs ,when operating in cooperative that the hybrid architecture is the most appropriate
mode ; g) Optimal resource management. architecture for real-world autonomous systems ,
which has to accomplish their pre-assigned
This paper describes the architecture of ARICS , mission and goals , autonomously , while operating
the architecture of the Mission Manager, the under severe schedule , environment conditions,
architecture of the main FMs , the data flow information uncertainty, and resources constraints .
between the processes , as well as , design
principles and implementation issues. 2. EIesien Guidelines

1. Introduction The design of AR[CS follows a set of guidelines ,


which is being established along with the system
Several approaches and architectures has been development process . The need to establish such a
proposed for the control of high autonomy AUVs . set of guidelines , stems from the lack of
For survey papers,see [ 13,[ 2 ] [3].
, These approaches established experience in the area of autonomous
can be classified into four main categories : a) control . An effort to establish a design
reasoning-driven model-based functional hierarchy methodology has been undertaken by NIST [4].
(e.g., NISTs RCS , NASREM) ; b) reactive- Derivatives of mme results in [4] are also
reflexive behavior hierarchy (e.g., subsumption, implemented in A!RICS . Nevertheless , one has to
some Aniamt approaches) ; c) behavior-based base its design process on his or her engineering
(e.g., Maes,Kaelbling,Mataric,Firby approaches); experience , as well as on currently available
d) hybrid architecture (e.g., NPSs RBM, SSS, theoretical foundations, engineering tools , and
Hughes,Lockheed,Boing, schema). More details on system engineering procedures and practice.

0-7803-3 185-0/96$5.0001996 IEEE 238


The following principles and factors guides
ARICS development process :

Hybrid architecture . The functional architectura of Hvpothesis-Driven Response . The decision on


ARICS is hybrid. It is organized in a tri-he1 response to exceptional event is implicitly based
hierarchical structure , while also incorporating on multiple hypothesis testing . The decision
typical features and mechanisms of ron- making process does not depends on cause
hierarchical and reactive architectures . As typical identification .
to functional hierarchy architectures , ARICS has Data Association and Fusion .ARICSs high level
strong real-time model-based reasoning and functionalities use mechanisms for data fusion and
planning functionalities . On the other hand , association .These functionalities uses data from
ARICS also has some features which are typical to various sensors and data bases. It is related to
reactive-reflexive architecture, such as : direct sensor fusion, to data base fusion , as well as to
connection of sensor inputs to actuating devices , sensorldata base fusion .
intra-level information flow between FPMs in the Multiple Computational Paradigms . ARICS
same level, direct information flow between FIMs employs multiple computational paradigms . There
in non-adjacent levels, or distributed local models is no one dominant or winning computational
and data bases. ARICS also Also , ARICSs lowest paradigms. There is an attempt to choose the best
level , Level I11 , is organized as a reactive- approach for the problem to be solved.
reflexive architecture . Another aspect of the Inter-Process Svnchronization .The operation of
hybrid approach is that the planning function is the FPMs in ARICS is inherently asynchronous.
reactive , i.e. , it based its planning on inconung However , in order to avoid problems of
feedback from all levels. unpredictability due to conditional branching , and
Architecture Openness and Modularity . Due to the to processing time variations , the control flow is
high complexity of the system , and to the expected not altered by event driven interrupts. Exchange of
future system expansions along the long life cyi:le , data between FFhds is done in a fixed interval
the requirements for architecture openness and control cycle . Read-write operations are done in
modularity are good engineering pracl ice. each control cycle
Functional modularity enables the decomposition Data Coherence .Each data element, e.g.,
of the functionalities into manageable FPMs , and navigation vector , is generated and broadcasted by
thus to simplify the development, integration, a sole specified source. This source generates the
validation , verification and field testing of the data , even if the process output is a result of raw
system. Open architecture and the use of standard data that has been gathered from several sources ,
building blocks , enables seamless future e.g., sensor suit. ,4 broadcast messages is used for
expansions , and simplify the integration of further sending data to several users simultaneously.
modules into the system. Behavior Determinism .Behavior determinism is
Information Processina Control .ARICSs high extremely important in complex systems such as
level information processes , e.g., reasoning, AUVs. Within the context of autonomous systems
planning,mission management,mission monitoring , behavior determinism means that under the same
,exception handling , are guided by the mission set of context , conditions and events , the system
goals , and by the current mission context and behavior will be consistent and repeatable.
situation. Some processes are triggered and driven Behavior determinism enables to predict future
by events. system behavior , if the set of context , conditions
Responsiveness Multiplicity .ARICS operate!; in and events , and its temporal evolution is
three independent modes of response , which are determined . Behavior determinism does not mean
implicitly embedded into the control algorithms that ARICS cant process non-deterministic data.
and into the decision trees. The response modes On the contrary . ARICS processes data which is
are: a) reflexive-algorithmic response, e.g., route represented by statistical or fuzzy metrics.
tracking guidance law ; b) reasoning-driven pre- Redundancv. ARKS supports redundancy, by
defined response, i.e. a pre-defined control law or providing mechanisms for redundancy
an action plan is selected from a data base , management. In case of module failure , a back-up
according to an identified situation; c) reasoning- hardware module ,or a back-up functional module ,
driven reactively planned response, i.e. an action replaces the failed module.
plan is planned in real-time, as a result 01 an Testability . ARICS is designed to enable and to
identified situation.Reflexive-algorithmic response support the use of formal tools , for validation and
mode is typically used at the lowest level - level I11 verification.
, while the reasoning-driven response modes are
typical to levels I (upper) and I1 (intermediate). 239
3. Functional Architecture incoming instructions , into operation commands ,
input signals or commanded set points.
General
Functionally , the management , command, data Three communication links enable data transfer
processing , and control functions of ARICS, are between the various modules across the
organized in a tri-level architecture , in which : a) architecture levels. . The main system bus , which
Level I (top level) is the mission organization is implemented by a VME 64 parallel bus ,
and management level ; b) Level I1 (intermediate interconnects the ETMs in level I and in level I1
level) is the systems coordination and operation . A high speed parcallelcrossbar switching network
level ;and c) Level I11 (bottom level) is the interconnects WM!s in the MM with the Global
control and execution level . Although the Memory/Data Base: module . Interface link enables
architecture is organized in a tri-level hierarchy , data transfer with the hardware systems in level
the functional architecture is hybrid, and does not I11 Some hardware systems requires customized
follow the classic hierarchical structures. In U 0 ports .
ARICS system, there are intra-level inter-process
information exchange , inter-level information A block diagram of ARICS functional architecture
exchange ,as well as fully reactive sensing-to- is given in Fig. 1 .
action loops at the bottom level , the execution
and control level. Mission Manager
In variety of AMCs under development by several
Level I , the top level of the architecture , is research groups , the top level is operating at a
composed of the Mission Manager (MM). The role single sequential fllow loop , where the processing
of the MM is to perform the high level modules are activated sequentially. However , due
functionalities of ARICS , and to plan , monitor to ARICSs generic structure and in order to meet
and manage the AUV operation , so as to the required performance in its whole spectrum of
accomplish the assigned mission goals. The MM applications , ARICSs MM is composed of
transforms the mission plan into scheduled tasks to interacting FTMs that are operating concurrently
be performed by the systems , i.e., what to do i n and asynchronously, rather than sequentially . The
order to achieve the mission goals. The MM itself main FPMs of the MM are :a)Mission Sequencer/
is composed of several interacting FPMs that are Executor ;b) Plan Interpreter; c) MissionBystem
operating concurrently and asynchronously. Monitor ; d) System Coordinator ; e) Exception
Handler ; f) Global Planner; g) Evaluator/
Level I1 , the intermediate level , is composed of Simulator; h) Cooperation Coordinator; i) Plan
System Manager FPMs . Each System Manager Dispatcher. As mentioned above, the FPMs are
(SM) is associated with , and is in charge of , a operating concurrently and asynchronously , under
specific functional area , or a specific AUV the control of the Mission Manager Control
system. Each SM transforms its assigned tasks into (MMC) module. This module coordinates the
operational instructions to be performed by its operation of MMs FPMs by generating Start/Stop
subordinate system at level I11 ,i.e., how to commands and Sync. messages. The FPMs report
execute the assigned tasks. The FPMs in Level I1 to the MMC their processing status.
, are : a) Mobility (Flight) Manager ; b)
Navigation Manager (including obstacle avoidance The operation of the MM proceeds as follows. A
function); c) Sensor Manager ; d) Armament Mission Plan (MP) which was generated by the
Manager; e) Payload Manager ; f ) Communication Mission Planning System (MPS) is downloaded to
Manager ; g) Auxiliary Systems Manager. ARICS, along with the associated Data Base.
Based on the MP , the Plan Interpreter FPM
Level 111 is composed of the hardware systems , generates and transfer three data elements : a)
and their associated embedded processing units . Monitoring Paramleters to the MissiordSystem
The systems are : a) Propulsion and Steering Monitor FPM. Thlese parameters are used for
System; b)Navigation and Obstacle Avoidance mission execution monitoring , and Mission level
System;c) Sensors (Mission Critical); d)Armament; exceptional events ldetection; b) Plan Graph to the
e) Mission Payload ; f) Communication System ; g) Mission Sequencer,Executor FPM ; c) Execution
Auxiliary Systems . In the current application, the Plan to plan memory and to the Plan Dispatcher
Navigation and Obstacle Avoidance System , as FPM. The Mission Sequencer/Executor FPM
well as the mission critical Sensor System has advances the mission phases as defined by the
their own embedded processing units. Each system Plan Graph. The nlission plan is represented by
has its own control element which transforms the hierarchical finite state machines. The transitions
between mission states or sub-states are triggered
240
either by conditions or by events . In case of Special mechanisms , based on a formalism of
nominal operation , the MissiodSystem Monitor hierarchical finite state machines , are used to
FPM report on plan event , which means that govern and to coordinate the operation of the
nominal conditions for state transition has be en concurrent processes , in concert . The formalism
met. In the case of exceptional event , the which is used is Statecharts and ActivityCharts ,
MissiodSystem Monitor FPM reports to 1 he and the software package and environment which
Exceptional Handler FPM , which than decides on supports this approach is STATEMATEB, see
the response. Depending on its decision , the latter [ 5 ] , [ 6 ] . The software package provides system
FPM transfer the relevant data to the Mission definition graphical tools , formal analysis tools , C
SequencerExecutor FPM . In case that a code (or ADA) generator , as well as
replanning is required , the Global Planner FPM is documentation and configuration management
activated , and performs the required algorithniic tools.
process . Optional plans can be evaluated and
ranked by way of real-time simulation , performed System Managers
by the SimulatorEvaluator FPM . Upon planning The major System Managers (SMs) ,i.e., Mobility
completion , the updated plan is send to the Plan Manager , Navigation Manager , Sensor Manager
Interpreter. The plan is segmented by mission has similar building blocks (FPMs) like the MM .
phases and schedule , as well as by funcrional Particularly, they has the following main FPMs:
areas , e.g., Navigation and Obstacle Avoidance. a)System Sequencer/ Executor ;b) Plan Interpreter;
The Global Planner employs several algorithms , c) System Monitor ; d) Coordinator ; e) Exception
based on different computational paradigms. Each Handler ; 0 Local Planner/Data Processor;
algorithm is dedicated to solve a specific planning i)Data Dispatcher.
problem . The System Coordinator FFM
synchronize the plan execution. It provide Sync. 4. =em Specification
data to the Plan Dispatcher and to the SMs in
Level I1 . The Plan Dispatcher FPM send As the development of autonomous vehicles (AVs)
scheduled and coordinadet plan segments to the and their associate Autonomous Mission
SMs. The Cooperation Coordinator FPM enable Controllers (AMCs)i is emerged , and as the AVs
the operation of the AUV as a member of a goes from the research laboratories to field and to
cooperative group. It performs the local functicins sea trials , the need to apply well established tools
of a distributed-decentralized C31 function . For of system engineering ,become more and more
further details see [8]. critical. Nevertheless , most of the published
works, describing AMCs , does not give the
Fig. 2 defines the Data How Diagram (DFD) of appropriate attention to the problem of AMC
ARICSs M M . system specification. The system specification
process is a crucial phase in the development
After a successful completion of the pre-mission process of any non-trivial system and AMC is not
Build-In-Test (BIT) procedure, the MM is exceptional. The specification process has a direct
transitioned to WAIT state. A launch command implication on the system architecture , on the
generates the RUN-ON event which , in-turn , computational approach , as well as on the
trigger the transition of MM to RUN main state. hardware configuration and implementation.
RUN main state is an orthogonal state , i.e., its System specification is also important as a basis for
sub-states , which are associated with the various performance evaluation. ARICS specification set
MM FPMs, are activated independently of each includes over one hundred specification items. The
other. For example , the Global Planner FPM can specification items are grouped into five categories
be in either its IDLE main state is or in its as follows: a) general requirements; b) functional
PLANNING main state, while the Exception requirements; c) performance requirements ; d)
Handler FPM can indepentently be in either one of interface definition , e) environment requirements.
its main states. Upon entering the RUN state , all ARICS specification process has been
the FPMs enter into their default state IDLE. accomplished in an organized , systematic and
Leaving the IDLE state or the transition between modular way. The specification process, was found
states is coordinated by the MMC module. to be very useful for AFWS definition ,
performance evaluation , and fast prototyping .
Fig. 3 illustrates the main states of the major FPlVIs
in the MM with emphasis on the concurrent Few representative specifications examples, for the
operation of the FPMs. above mentioned categories a) , b) and c) , are
given in the sequel .
241
Examples for General Requirements .a) Changes cluster. This customized real-time operating
or modifications of hardware modules in level III , system also supports parallel operation of the PNs.
will not enforce changes in level I FPMs, or in ARICS software is written in C and C++
architecture; b) ARICS software security will meet languages.
computer security regulations .
Examples for Functional Requirements . a) The The hardware architecture is described in Fig. 4 .
time required for trajectory planning- optimal
mode shall not exceeds x10 times , the time
required for trajectory planning - fast mode ; 6. Summary
b) Priority of response combination will be
according to the following criteria ,in decreasing This paper describes the architecture and the major
priority order :1) time criticality or risk of elements of ARICS Autonomous Mission
immediate mission loss ; 2) risk of performance Controller for high autonomy AUV. The system is
degradation or future mission loss ; 3) safety to in its advance development phase. More details are
troops ; 4) safety to AUV ; 5 ) resource economy . given in [7] .
Examples for Performance Reauirements . a)The -
Acknowledgment
time required for on-the-move mission planning of
a complete mission , will not exceed T1 ;b) The The work described in this paper is being
time required for mission segment replanning will supported by RAFAEL and IMOD.
not exceed T2 ; c)Hardware failure detection
probability will be greater than 0.990 ; d) False
References
alarm probability during BIT 1 procedure will not
[l] W.D.Hal1 , M.B.Adams , Autonomous
exceed 0.02 ;e) Exceptional event detection
Vehicle Software Taxonomy, in Proceedings
probability will be greater than 0.950 .
of the IEEE 1992 Symposium on Autonomous
Underwater Vehicle Technology ,Washington, DC,
5. Hardware Configuration June 2-3 , 1992, pp. 49-64.
[2] G. Veruggio et al., Architectures for
ARICS is implemented by a real-time multi- A W S : A Comparative Survey of Some
processor computer , installed in a VME 6U Experiences in ]Proceedings of the AUVS 95
chassis . The computer topology is a bus network Symposium , Washington, DC, July 10-12, 1995 ,
topology. A VME 64 bus is the main system bus . pp. 164-178.
It connects all the units. It supports data transfer at [3] A.J. Healy,A.M. Pascoal , F.L.Pereira ,
peak speed of 70 Mbytes/Sec. The standard Autonomous Underwater Vehicles: An
wordlength is 32 bit . The computer is managed Application of Intelligent Control Technolgy, in
by a Motorola 68060 SBC board which is the Proceedings of American Control Conference,
system run-time host . The board has 64 Mbyte Seattle, WA., June 1995, pp. 2943-2949.
Error Checking and Correcting (ECC) DRAM 141 R. Quintero, A.J.Barbera, A Real-Time
memory. The main processing power is provided Control System Methodology for Developing
by a cluster of four (4) Processing Nodes (PNs) Intelligent Control Systems, NIST Report NISTIR
which resides on a single VME 6U board . Each 4936, October 1992.
PN consists of : a) 1 Power PC 603e RISC [5] D.Harel,Statecharts: A Visual Formalism
processor ; b) 16 Mbyte ECC DRAM ; c) DMA for Complex Systems , Science of Computer
controller ; d) Crossbar network switch ; e)
Operating system support hardware .The PNs
m, vol. 8 , pp. 231-274, 1987.
[6] STATEMATE , User Reference Manual
cluster can be operated in variety of modes, Ver 6.1 , i-Logix 1.nc. , 1995 .
including parallel processing. In addition to the [7] A. Yavnai et al., ARICS - Autonomous
VME 64 bus , there is a high speed crossbar Mission Controller, Internal Technical Reports ,
switching network ,peak transfer rate of 160 RAFAEL.
Mbytes/Sec , which connects all the PNs and the [8] A. Yavnai , Distributed Decentralized
Global DRAM. Memory boards includes : a) 256 Architecture For Autonomous Cooperative
Mbyte DRAM memory board ; b) 64 Mbyte Operation of Multiple Agent System, in
NVRAM memory board . Interface ports include : Proceedings of the IEEE 1994 Symposium on
a) Serial RS-232 ; b) Serial RS-422 ; c) Mil-Spec Autonomous Underwater Vehicle Technolow
1553B ; d) SCSI to hard disk ; e) Ethernet (10 ,Cambridge, Mass., July 19-20, 1994, pp. 61-67.
MHz) to development workstation. Real-time
[9] J. Fogelin ,The VxWorksm Real-Time
operating system is Vx-Worksm [9] . Customized Kernel , Wind River Systems , Inc.
real-time operating system is used for the PNs
242
'I TO DATALINK I I
I
I I
I Data
Manager I
I
I VME64 BUS
Comm.
I VME64 BUS
I
I

1
I I
I
I
I I
I Auxiliary
I Comm.
Systems
I Manager I
Manager
I I
I I
I
I
X-BAR I I
I
I
I (GLOBAL
I
IMEMORY
I
I ARCS L A
L,
I_ I 4.3 I
I/O PORTS I "O I
I/F I/F
3.6 3.4 3.3

AL
Auxiliary Comm.
Armament Sensors
Systems System Avoidance

AUV SYSTEMS

Figure 1 : ARICS ARCHITECTURE

243
Mission Plan
Global 13ata Base

Process
Report Events I

Coordinir

\.sync.
* Figure 2 : Mission
Manager DFD

244
( MISSION SEQUENCER

- _ _ _ _failed
_ _
MONITOR on command / ir

plan ulndated i
updote monitor porome ers

GLOBAL PLANNER

RE-PLANNING

- _ _ _ _ _ _ _ - _ _ _ _
SYSTEM COORDINATOR

SCHEDULiNG

_ _ - _ _ _ _ _ ~ _ - _ _ - _
EXCEPTION HANDLER

RESPONSE
in done I send results
_ _ - _ _ _ _ - _ _ - _ _ _

+--
EVALUATORISIMULATOII

IA IDLE I simulation command I read data


EVALUATING1

SIMULATING

- _ - _ - _ _ ~ _
COOPERATiON COORDINATOR
site app. 1 set C:C on + read data

COORDINATIh
site leoved I set CC off

Figure 3 : MISSION MANAGER PROCESSES AND STATES


_ _ - _ - - -
1 Power PC 603e 1
I 16 MBECC DRAM
I
2- DMA Controller
X-Bar Switch
i

VME64 BUS
I
i/O PORT

SERIAL

SCSl (la HD)

ETHERNET (to wo!!dobn)

Figure 4 , ARlCS HARDWARE ARCHITECTURE

245