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