DCS Architecture

1
DCS Architecture

• Bob Krzaczek

2
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.

3
Key Design Requirements

• The DCS design must possess these attributes
• Modular
• Extensible
• Maintainable
• Continuous Improvement

4
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.

5
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.

6
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.

7
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.

8
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)

9
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

10
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 vendors systems

11
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

12
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

13
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

14
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

15
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

16
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

17
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.

18
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

19
Data Acquisition

• Data Acquisition is modular.
• Modularity insulates the DCS from instrument
  specifics.
• The DCS translates an experiment to instrument
  specific commands.

20
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

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