DCS Architecture Bob Krzaczek

Key Design Requirement Distilled from the DCS Mission statement and the results of the Conceptual Design Review (June 1999): The DCS must support and benefit from continuous improvement, both in itself and within the SOFIA program, over a twenty year lifetime.

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

Data Reduction Resources FSI & MCS Interfaces Task Library DCS Storage User Interaction Layer SSMOC Internet DCS Functional Architecture