UMN AEM UAV Software Architecture Overview

Document Sample
UMN AEM UAV Software Architecture Overview Powered By Docstoc
					UMN UAV Software Architecture Overview
Version 0.3
Author: Eric C Lobner

Architecture Overview
A layered architecture has been chosen for the UAV software platform due to the inherently
hierarchal nature of the system components. In many ways, the core function of the UAV software
platform is to provide an appropriate level of abstraction at each level to ensure the type and detail
of information is sufficient to accomplish the desired functionality without extra overhead. A layered
architecture also fits well with the UAV software platform because of the way multiple layers
partition a complex problem into simple structures with increasing levels of abstraction. At the
lowest level of abstraction, the hardware platform layer, the logic is hardware based and very
primitively focused. At the uppermost level of abstraction, the application layer, the user is able to
specify high level logic surrounding aircraft control, navigation and other logic without having to
worry about the low level details of the hardware platform. Lastly, the layered architecture is ideal
for the UAV software platform because of the support for replacement and extension at all layers of
abstraction. One of the core requirements of the UAV platform architecture is building in the
ability to add new hardware devices (GPS sensor, Actuator, etc...) to the system without having to
spend a significant time re-programming multiple or existing components of the system. Using a
layered architecture allows device level changes to be isolated to the Devices layer, where changes
can be made without modification being required at layers above or below the modified layer. For
all of the above reasons, a layered architecture has been chosen as the optimal choice for the UAV
software platform.

Architecture Detail
The lowest level of the architecture, the hardware platform, represents the concrete physical
elements of the system. The current UAV platform architecture is based around the Power PC
MPC5200 series of microprocessor. This processor runs the real-time operating system eCos which
provides execution time services to the rest of the software components. The second layer of the
architecture, and the only layer to interact with the hardware components, is the Communication
Channel layer, which serves to create an abstraction region between the various communication
devices and the rest of the software stack. The CommunicationChannelBase component provides
the highest layer of channel abstraction and hides all detailed communication and only provides an
interface to send a command and receive a response. The specifics of how each command channel
handles the send command is defined in the various command channel implementations.

The next layer of the architecture represents the software encapsulation of each aircraft device
within the system. Aircraft devices represent either sensors or actuators at the current moment.
The device layer interacts with the communication channel layer to provide the link between the
software component and the actual hardware chip connected to the communication bus. Above the
device layer is the Task Services layer which defines the basic functionality of the five tasks within
the system. The Altitude and Heading (AHRS) task is responsible for current movement state of
the aircraft. The Control task is responsible for applying control laws to the aircraft control
surfaces to move the aircraft in the desired direction. The Data Acquisition (DAQ) task is
responsible for acquiring data from the sensors and recording the current state of the aircraft. The
navigation task is responsible for providing new directional data to guide the aircraft into the
correct direction. Lastly, the Telemetry task is responsible for communicating and recording the
current state of the system to the ground monitoring station and logging equipment.

Each task in the UAV platform is accompanied by a task manager object which provides core
services and initiates execution of the user defined task interface implementation (task strategy)
within the application space. Each task is executed at an interval specified by the configuration of
the system. When each task is executed, the Task manager is responsible for performing basic
functionality core to each task. This generally involves retrieving information from the DataHub
component that can be executed through the task strategy that has been provided by the
application layer.

The application layer represents the users level of interaction with the system, and provides users
the ability to configure and provide implementations for the various task logic and fault models
within the system. Each task within the system presents an implementable interface for which the
Application layer can provide an implementation to control the operation of the aircraft. In addition
to providing implementations to the task logic, the application layer allows implementation of the
FaultModel module to support injection of faults and errors throughout operation of the system

Architectural Viewpoint Considerations
A view in the software architecture realm is a means of analyzing aspects of the candidate
architecture against a set of related concerns. The following view have been selected and analyzed
against the candidate UAV software architecture:

Functional View
The purpose of the functional view is to address the design of the operational software elements
required to complete the system requirements. The functional view is fully explained in the
companion document UMN AEM UAV Software Design Overview.doc.

Concurrency View
The purpose of the concurrency view is to analyze the coordination and control of executing tasks
within the proposed architecture. Concurrent executing tasks play a major role in meeting the
required timing requirements of the UAV software platform. Each task within the system (AHRS,
Control, Data acquisition, Navigation and Telemetry) execute within a distinct task that operates at
a period configurable by application layer constructs. Two elements have been implemented within
the candidate architecture to provide control over concurrency within the system. The first
element is the real-time operation system, eCos, which the entire UAV platform is built upon. The
eCos system provides runtime and operating system services to the rest of the application and
provides for constructs to create and execute thread objects. The second element is the
synchronized data repository module called DataHub, which is responsible for synchronizing access
to shared data between the various tasks within the system. All communication between tasks takes
place through data, which is controlled by the DataHub element to ensure that concurrency issues
do not occur during operation of the system.

Development View
The purpose of the development view is to provide design to support the extension, modification
and adaptation of the UAV software platform. One of the core features supported by the UAV
platform is the ability to provide users overridable interfaces with which they can change the core
behavior of the aircraft. Being designed primarily for student researches, the extension elements
must be easy to understand and provide the proper level of detail from which to override with
desired behavior. Software objects within the UAV platform have been established to facilitate the
adaptability by creating interfaces and using the functional strategy pattern extensively to create
plug-in ready adaptability. For additional information on specific extension points and extensibility
details, review the companion document UMN AEM UAV Software Design Overview.doc.

Case Study – Implementing a new task strategy
The objects contained within the task services layer provide the key components to support the
extensibility required by users of the platform. As a research platform for aviation controls
research, it is critical that elements of the platform be designed to support implementation of new
behaviors and design. When a new component, be it hardware, software or logic, is introduced into
the system, the user is required to only implement pieces of the platform and override default
behavior with their desired logic. For example, imagine a researcher is testing the correctness of a
new sensor fusion module for combining inputs of several altitude sensors into a single reading. The
researcher will first need to ensure that the required hardware support is in place to implement
multiple sensors. From a software side, this researcher will have contact with only a single
component of the system, assuming that the hardware/device level code has already been written
(i.e. adding another sensor to the system that already has a device communication module written).
This researcher would only need to override the DAQ task strategy with their new logic. This new
strategy would be responsible for communicating with both sensors via the communication
infrastructure, reading the sensor values, performing the voting model and storing the results into
the DataHub. After making a change in the external configuration file to the platform, the
researcher is ready to test his logic. The remainder of the platform function is not impacted by his
change and will continue to operate without impact or requiring further modification.

Future Enhancements
At the current date of publish, the architecture is as complete as possible for all requested
functionality. Functionality that may be planned for the future releases includes better supporting
for execute Hardware In the Loop (HIL) and Processor In the Loop (PIL) simulations of the
platform, as well as support for replacing modules of the architecture with models from a Matlab
SIMULINK environment. In addition to supporting new runtime features, the design time ability to
generate code from modeling and simulation tools like SIMULINK is desired. It is the belief that the
current architecture will scale to support these and other future enhancements to the UAV software