PALM-3000 Software Architecture T. TRUONG Team Meeting #7 27 February 2008
Dec 22, 2015
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-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.”