1 / 20

DCS Architecture

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.

Download Presentation

DCS Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DCS Architecture Bob Krzaczek

  2. Key Design Requirements The DCS design must possess these attributes: • Modular • Extensible • Maintainable • Continuous Improvement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related