Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | frances-woods |
View: | 187 times |
Download: | 12 times |
DCS Architecture
Bob Krzaczek
Key Design Requirements
The DCS design must possess these attributes:
• Modular• Extensible• Maintainable• Continuous Improvement
Key Design Requirement: Modular
• The DCS must not be a monolithic program.
• The DCS must not be a single computer.
• The DCS shall be a collection of small independent services, residing on multiple machines, providing functionality on an “as needed” basis.
Key Design Requirement: Extensible
• We must support the easy incorporation of new procedures or techniques to the DCS repertoire.
• The DCS will provide configuration management for test and evaluation of new components, while maintaining access to established “proven components”.
Key Design Requirement: Maintainability
• The DCS must not be tied to any specific vendor or platform.
• We shall use open, community-accepted standards and technologies.
• The DCS must be well documented, both in design and in implementation.
Key Design Requirement: Continuous Improvement
• A consequence of building a modular, extensible, and maintainable system.
• Continuous Improvement is the core capability of the SOFIA program.
DCS Technologies
Two underlying attributes facilitate the DCS design:
– Distribution of and communication between objects across the system
– Extendable and flexible information exchange format (for both data & documentation)
Object Distribution and Communication
CandidatesCORBA: Common Object Request Broker
Architecture* Selected *
DCE: Distributed Computing EnvironmentNot widely implemented
DCOM: Distributed Component Object ModelProprietary Microsoft technology
RMI: Remote Method Invocation (Java)Only supported by Java
RPC: Remote Procedure CallNot object oriented
Why CORBA?
• Defined by the Open Management Group, a consortium of over 600 academic and industrial members
• Provides the underlying support for easily distributing DCS objects across one or many machines
• CORBA supports two important facilities: object oriented development, and distributed computing
• CORBA insists on interoperability between different vendor’s systems
Information Exchange Candidates
FITS: Flexible Image Transport SystemOriented towards “flat” data: images, arrays, tables
HDF: Hierarchical Data FormatSize limitations, inflexible data typing
SGML: Standard General Markup LanguageEpic complexity, difficult to parse all valid forms
XML: Extensible Markup Language* Selected *
Why XML?
• XML, the Extensible Markup Language– Defined by the World Wide Web
Consortium, a standards and protocol generating organization with over 400 academic and industrial members
– Provides simple communication of “rich” structured information within the DCS
– Very easy to transform into other formats
Why XML?
• XML, the Extensible Markup Language– A descendent of SGML, XML has become
the universal format for structured documents and data on the Web
– Easy to add new format definitions– “Backwards compatibility” is readily
supported as DCS formats evolve over the next 20 years
We Are Not Alone
• FLITECAM also selected CORBA to provide its object oriented foundation
• HAWC also selected XML for data exchange and representation as well
• MCS also selected CORBA to provide its object oriented foundation
DCS Implementation
In order to be easily adapted to a variety of current and future instruments:
• Raw instrument data will be archived along with all other experiment data (e.g. observation plans, reduction pipelines, housekeeping data, flight logs)
• Data reduction pipelines will support variety of languages
User Interaction Layer
• Common interface for user to all DCS resources
• The “DCS experience” is customizable on a per user basis without affecting rest of DCS
• Leverage off the web and related tools for providing access regardless of geographic location
Task Library
• Provides sophisticated tasks that replace sequences of human actions.
• Easily extended with new activities and procedures.
• Responsive to DCS extensibility requirement.
• “Once you know how to do it, we can automate it.”
DCS Data Capture
• Captures “everything necessary …”e.g. raw instrument data, reduced data,
observation plans, flight logs, flight plans, instrument modes, pipeline parameters, science personnel
• By virtue of incorporating XML, supports export and import of all data and documentation with customers and partnerse.g. IPAC
Data Acquisition
• Data Acquisition is modular.• Modularity insulates the DCS from
instrument specifics.• The DCS translates an experiment
to instrument specific commands.
Pipelined Data Reduction
• Instrument science teams focus on developing algorithms; no need to be a “DCS expert” (analogous to the GI role)
• Computation is distributed, supporting parallel computation where possible
• DCS Data Reduction removes the need for every GI to have their own compute servers
Data Reduction Resources
FSI & MCS
Interfaces
Task Library
DCS Storage
User Interaction
Layer
SSMOC
Internet
DCS Functional Architecture