
Middleware Software Demonstration Overview
Explore the middleware software demonstration by Dave Mills at LSST/NOAO. Learn about the system high-level view, requirements, and service abstraction layer concepts. Discover how the service abstraction layer supports telemetry and commands, generates test code, and more.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Middleware Software Demonstration Dave Mills LSST/NOAO
Overview DDS concepts SAL description Demonstration Current status Release schedule
Requirements : Ten year survey stable system Comprehensive logging Status health, trending Command history Environment Support subsystem communications Diverse vendors Consistency and coherence Standards Maintenance and Debug Leverage external tools
Service Abstraction Layer SAL System Dictionary Object definition (import/export/validation) Code Generation Test applications / Simulators Facility Database support
System Dictionary Systems and subsystems Devices Properties Actions Units Consistency Application software Communications middleware Operations/Engineering interfaces Facility Database
Service Abstraction Layer Based on system dictionary elements Supports Telemetry definition Supports Commands definition Supports Events definition Generates interfaces Generates test code Generates sample application/simulations Generates sample database Generates documentation
SAL Objectives Insulate developers from lower levels Support application level abstractions Telemetry datastreams Command/Acknowledge Automatic logging (to Facility Database) Consistency checking Timestamps/deltas (PTP) Autogenerate interfaces Strongly typed / runtime checked
Requirements : Linux (x86,x64, baseline is CentOS 6.4) With standard development tools installed OpenSpliceDDS* Boost libraries* Python* Java* Tcl* Postgres^ Labview^ *included in SDK distribution (~800Mb) ^for future releases
ICD Command definition 2.1.1 pivot {} command ID: TCS-HEXROT-CMD-ICD-0010 Last Modified: 12/10/2012 Specification: The pivot command shall cause the Hexapods to update the pivot point coordinates. Parameters: x, y, z: absolute positions for the pivot point in microns. By default, the pivot point is located at the origin at 0, 0, 0. Discussion: The Hexapod will report when the new values have been applied. The command sequence will be as follows: - TCS issues command pivot parameters - Hexapod acknowledges with response: o Accept if command accepted and being acted upon. o Error if Hexapod can t perform the command. - Hexapod generates one of the following events at the end of the action: o Done move, if the command completed correctly. o Error move, if the command ended with an error.
ICD Telemetry definition 1.2 Hexapods and Rotator telemetry publication ID: TCS-HEXROT-CMD-ICD-0003 Last Modified: 12/10/2012 Specification: The Hexapods and Rotator shall publish telemetry organized as topics. Discussion: The Hexapods and Rotator telemetry comprises a wide range of parameter values intended to be sufficient to understand the state of the subsystem. Typical examples would be temperature, positions, voltages, velocities, etc. The definition and structure of the topics to be published is specified in the Appendix of this document. 1.3 Hexapods and Rotator telemetry time-stamp ID: TCS-HEXROT-ICD-0004 Last Modified: 12/10/2012 Specification: The Hexapods and Rotator shall time-stamp all published telemetry. Discussion: The publication mechanism (provided by TCS) along with Hexapods and Rotator time-stamps, are intended to be sufficie with a particular image.
ICD Event definition 3 Event publication ID: TCS-HEXROT-CMD-ICD-0023 Last Modified: 12/10/2012 Specification: The Hexapods and Rotator shall publish events whenever a change of state happens. The list of events will be published in the appendix of this document. Discussion: Events are the primary means to rapidly communicate changes in the state of a subsystem, triggered by commands, by internal behavior, or when a monitored value exceeds the limits defined in an alarms configuration table. Using the middleware capabilities of selecting QoS s, events are given higher priority of transfer as compared to regular telemetry. This capability allows for quick response in case of alarm events. Events are an integral part in the sequencing of commands activities, as illustrated before. The descriptions of the events of the subsystem are to be found in the Appendix of this document.
Object definitions ###------------------------------------------------------------------------------------------- ### COMMANDS ###------------------------------------------------------------------------------------------- #type device # command target position command target position command actuators pivot ###------------------------------------------------------------------------------------------- ### EVENTS property action value+modifiers | alias ###------------------------------------------------------------------------------------------- #type id ### ### Event move Event move Event track Event track Event limit property parameters home set | home double double double double | move angle | pivot x y z done error lock lost direction string string string struct hexapod_LimitSensors { short liftoff[18]; short limit[18]; }; struct hexapod_Metrology { long distance[18]; long error[18]; short status[18]; }; struct hexapod_Actuators { long Raw[18]; float Calibrated[18]; };
Demo SDK operations Validate definitions Generate code Review Tests
Web based interface Define Telemetry/Commands/Events Edit/Clone pre-existing types Edit metadata (Qos,Units,Doc) IDL/XML upload Generate C/C++/Java/Python/LV interfaces Generate unit tests, simulators Generate documentation Generate sample database tables
Current Status Linux 32-bit OpenSplice V6.x C++ / Java / Python Interfaces (shared libraries/jar) Test applications / gui
Current status ICD equivalent interfaces for Camera Dome Hexapod / Rotator Prototype interfaces for All other subsystems
Release Schedule Sep 2014 V2 Current version as described here via download Web interface will go live 2015 V3 ICD equivalent support for all subsystems Initial OCS/TCS simulator Prototype Facility Database 2016 V4 ISO C++ support Set of subsystem simulators 'Realistic' Facility Database Live operations simulator