DCS Architecture - [PPT Powerpoint] (2024)

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