240 likes | 474 Views
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.
E N D
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 Candidates CORBA: Common Object Request Broker Architecture * Selected * DCE: Distributed Computing Environment Not widely implemented DCOM: Distributed Component Object Model Proprietary Microsoft technology RMI: Remote Method Invocation (Java) Only supported by Java RPC: Remote Procedure Call Not 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 System Oriented towards “flat” data: images, arrays, tables HDF: Hierarchical Data Format Size limitations, inflexible data typing SGML: Standard General Markup Language Epic 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 partners e.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
FSI & MCS Interfaces DCS Storage Internet User Interaction Layer Data Reduction Resources Task Library SSMOC DCS Functional Architecture