PALM-3000

Software Architecture

T. TRUONG

Team Meeting #7

27 February 2008

PALM-3000Agenda

• Architectural Goals• Constraints and Strategies• System Architecture• Database Architecture• GUI Architecture• Toolchain

PALM-3000

3

Architectural Goals

Ranked in order of decreasing importance:

• Performance– Split-phased, active-message based architecture, improved database engine.

• Modular construction– Component based architecture.

• Flexible composition– Interface-driven, distributed architecture.

• Reliability– No dynamic memory allocation after initialization.

• Extensibility– Table driven command processor, component based architecture

• Maintainability– Automated document generation similar to JavaDoc.

PALM-3000Architectural Constraints & Strategies

• Within the schedule and budget constraints for 2009 delivery.

• Reuse existing code wherever appropriate.

• Incorporate publicly available proven toolchains and libraries.

• Incremental delivery if necessary.

PALM-3000Software Context Overview

P3KAOTCS

ScienceInstruments

LGS

BTO

Control

Data

AO Operator

PALM-3000

6

Architectural Highlights

The PALM-3000 software architecture is…

• Component-based• Interface-driven• Split-phased• Distributed• Active-message-based

PALM-3000Component-Based Architecture

• Similar to objects– Define functions and allocate state.– State variables are strictly private.

• Different from objects– Components are singletons – can’t instantiate them.– Modeled after hardware – can’t instantiate control regs and output pins.– Code reuse via templates and parameterized interface.

• Use purely local namespace– A calls C and B calls C. Yet A and B refer to different implementations

of C.

• Encourage modular design

PALM-3000Interface-Driven Architecture

• Components interact via bidirectional interfaces

• An interface = {commands} U {events}– Command = function to be implemented by the interface’s provider.

• Calls down the component graph.– Event = function to be implemented by the interface’s user.

• Calls up the component graph.

• A component must implement the events in order to call the commands of the interface.

• A component may use or provide multiple interfaces.

• Separate construction from composition.

• Enable dynamic composition.

• Allow underlying implementations to be replaced easily.

PALM-3000Split-Phased Architecture

• Invocation and completion split into two separate phases of execution– For a long-running operation, the call returns immediately. The

called abstraction issues a callback (event) when it completes.

• Fully event-driven• Keep the system responsive

– There is never a situation when an application needs to take an action but all of its threads are tied up in blocking calls

• Save memory– Determining the exact stack size is difficult in case of a blocking

operation. The OS often chooses a very conservative and therefore large size.

– Creating large variables on the stack is rarely necessary.

PALM-3000Distributed Component Architecture

• Based on proxy components – Shield the client/user components from the fact that the

underlying components are remote.

• All components have proxy capability.

• Use common library to enable proxy capability.

PALM-3000Active-Message-Based Architecture

• Active Messages provide the enabling mechanism for low-latency remote procedural calls.

• Provide messaging functionality for proxy components.

PALM-3000Implementation View

AOCP

HODM

LODM

HOWFS

LOWFS

TTM

UTT LGS

ACQMOTOR

LOWFP

BTO

TCS

PHARO

TIME

WLITE

AODR

AODS

HOWFP

Component runs Standard Linux on PC1 through PC8Component runs Real Time Linux on PC0

Component runs Real Time Linux on Telemetry PC Component runs Standard Linux on Cass Cage PC

Text Cmds Binary Cmds

Inteface User

Inteface Provider

Interface

PALM-3000Database Architectural Highlights

• Consists of two main components– AODR: Data recorder component.– AODS: Data server component.

• Provides publish-subscribe capability.

• Embeddable, in-memory, not client-server– Components may link directly into the application.– Run in the same address space as the application.– No interprocess-communication required.

PALM-3000

Database Architectural Highlights (Continued)

• Simple function-call API– Simple key/value lookup and store.– No query language (SQL) to parse.– No execution plan to produce.– Not a relational database– API binding for C, Java,and IDL language.

• Data stored in application-native format– No translation or mapping required.

• Configurable Cache– Provides fast access to memory-resident data.– Minimizes data stores to disk.– Exploits temporal locality of reference.

PALM-3000

Database Architectural Highlights (Continued)

• High concurrency– Multiple processes (readers and writers) on a single machine, or multiple threads

in a single process, can all use the same database concurrently.

• Transactions and recovery– Permit multiple changes appear at once.– Guarantee the database is complete and usable after a system or application

crash.

• Hot backups– Support backups while the database is in use, using standard Unix utilities

(dump, tar, cpio, cp, …)

Nothing more than key/value lookups with cache management plus transaction and locking support

PALM-3000Graphical User Interface

• Support multiple GUI clients– One controller with multiple viewers.

• Thin Java clients– No automation logic.– Decouple automation logic from GUI logic.

• XML-based user interface– Develops much faster and more easily than in ordinary Java.– Allows data binding (properties updated in real-time as values of

expressions change).– Supports powerful CSS stylesheet (enables skinning).– Separates logic from presentation.

PALM-3000Open Source Toolchain

• nesC– A component-oriented programming language, C-extension.– Compiler is an extension of GCC.– Compiler outputs C code or object code.

• nesdoc– Generate code documentation using simple tags.– Same concept as JavaDoc.– Can generate a component graph using dot.

• Berkeley DB– “The most efficient, most scalable, and fastest database engine

available today.”