Is the work?ow model a suitable candidate for an observatory
    supervisory control infrastructure?
    Philip N. Daly
    and Germ?an Schumacher
    LSST, 950 N. Cherry Avenue, Tucson AZ 85719, USA
    LSST, Colina El Pino s/n, Casilla 603, La Serena, Chile
    This paper reports on the early investigation of using the work?ow model for observatory infrastructure software.
    We researched several work?ow engines and identi?ed 3 for further, detailed, study: Bonita BPM, Activiti and
    Taverna. We discuss the business process model and how it relates to observatory operations and identify a
    path?nder exercise to further evaluate the applicability of these paradigms.
    Keywords: LSST OCS Control Software Business Process Model BPM Bonita Activiti Taverna
    The Large Synoptic Survey Telescope (LSST
    ) is a new generation telescope being constructed in Chile over
    the next several years. It will have an 8.4 metre primary mirror and the world's largest digital camera
    3.2 Gigapixels and carry out a 10-year survey of 18,000 degrees2 of the southern sky every few days. After 10
    years of operations, it will have visited every region of the southern sky ˘ 825 times with a total exposure time
    of close to 4 hours per region. The observing strategy will open up the time domain in astronomy and will lead
    to many exciting discoveries including millions of Type Ia supernovae used as dark energy probes, so-called near
    Earth objects etc. The public web site
    is open to scientists and non-scientists alike.
    LSST is, therefore, a complex system of systems with demanding performance and operations requirements. A
    major component of the LSST telescope and site software is the observatory control system (OCS) that schedules,
    coordinates, commands and monitors the observatory. In another paper,
    we provided a comprehensive overview
    of all of the meta-components of the OCS and the, de facto, loosely coupled interactions between such meta-
    components and we re?ected on a compartmentalized approach, recognizing the underlying modularity of the
    system, using a well-known scripting language. That approach describes the current baseline, which has been
    proven on prior initiatives such as the Southern Observatory for Astrophysical Research (SOAR) telescope.
    It is possible that these meta-components will be written in di?erent programming languages re?ecting the di-
    versity of their essential functionality. The underlying service abstraction layer (SAL
    ) infrastructure software|a
    cornerstone development of the OCS|will guarantee interoperability in such a heterogeneous environment. We
    also promulgated, in that paper, current status and plans that ?t the timeline of the construction schedule with
    current sta?ng levels and budget.
    On a parallel track, however, we have been investigating the work?ow model in lieu of a more traditional
    scripting approach. A work?ow can be thought of as a graphical representation of a virtual script. Software to
    support such systems already exists. In fact, a Google search on the term `graphical work?ow systems' shows
    just how many choices there are! For LSST, however, we require a Linux (only) run-time environment and wish
    to support the open source (code) model. Re?ning a search along these criteria rapidly reduces the number
    of options ... but it is non-zero. We took a rudimentary look at some choices (Decisions Platform
    , Joget
    Further author information: (Send correspondence to P.N.D.)
    P.N.D.: E-mail:, Telephone: +1 520 318 8438
    G.S.: E-mail:, Telephone: +56 51 205347

    and Kepler
    ) and have identi?ed 3 candidates for further, more detailed, study: Bonita BPM
    , Activiti
    . Note that this latter system already has some basic astronomical support for virtual observatory
    and in data reduction
    but not on the controls side of data acquisition.
    A suitable choice of work?ow system may provide a more integrated approach: an important aspect of this
    integration is that during work?ow execution, there is automatic coordination of operation of the seemingly
    individual components (elements and activities) that constitute the work?ow. Also, work?ows provide an easy-
    to-use way of specifying tasks that have to be performed during a speci?c sequence of operations. This `engine'
    providing the coordination of the work?ows is an integral and essential component of their software functionality
    and maps onto functionality that we would have to provide in the current OCS development over several meta-
    components. Taking, for example, the Bonita BPM software product we can map their 3 components onto
    functionality required by the OCS:
    Bonita UI Designer is a (web-browser) interface designer that allows us to satisfy many of the components on
    the Operator-Remote meta-component and provide consistent web-based interfaces over a range of devices
    (laptop, desktop, smart phone, tablet etc);
    Bonita Portal is the operator control center that also overlaps with components from the Operator-Remote
    meta-component and provides admin type oversight of the work?ows;
    Bonita (Run-Time) Engine runs the work?ows and so replaces the Sequencer meta-component. Taken to-
    gether, Bonita Portal and Bonita (Run-Time) Engine are also known as the Bonita Platform.
    Bonita BPM also provides the Bonita Studio: an integrated development environment (IDE) for their product
    which has many of the functionalities associated with, for example, IDLE or IntelliJ . Bonita BPM supports
    Java which is one of the programming languages supported by the SAL.
    Even though we are now in the construction phase of the project, we still have a modest window of opportunity
    (3{6 months) to evaluate this approach to leverage the impressive, open-source work?ow engines that are freely
    available. Part of this evaluation would be with respect to the schedule for OCS construction.
    In conventional control systems, some form of supervisory control and data acquisition (SCADA) paradigm|the
    generic term used for the conglomeration of hardware, software and procedures used to control and monitor
    typically industrial processes|is used to perform complex operational activities. New initiatives in this area
    emphasize open systems technology over proprietary systems and open-source over closed code.
    However, for LSST the strictly hardware-oriented control systems are dealt with at the subsystem level with
    the OCS providing supervisory control of the sequences and procedures. Because of this higher-level abstraction of
    control, we can contemplate a work?ow-based system which focuses on the whole, synchronized, data acquisition
    process rather than the intimate details of speci?c hardware control.
    In such a context, business process management can be de?ned as:
    `Business process management (BPM) is a systematic approach to making an organization's work?ow
    more e?ective, more e?cient and more capable of adapting to an ever-changing environment. A
    business process is an activity or set of activities that will accomplish a speci?c organizational goal.'

    Figure 1. Employee onboarding work?ow example. In this work?ow, we can clearly identify human-related tasks,
    automated tasks, error handling, sub-processes, delayed-action timers and multi-task synchronization points.
    Business process management is supported by a notation language, BPMN2.0
    , which is an Object Manage-
    ment Group (OMG) standard.
    Indeed, a BPM plugin for PrismTech's Enterprise Architect modeling tool (used
    by the project) is available for integration with the current model if desired but, note, that it does not provide
    run-time engine support. Also worth noting is that both Bonita BPM and Activiti support project export and
    import using XML so, in principle, we have a redundancy built in should one of these organizations cease to
    shows a typical business-oriented example of a work?ow: one for employee onboarding.
    Even in
    this diagram we can see various levels of interaction within the work?ow ... some human, some automated, some
    signals and timers and some error handling. More important is what you do not see within the diagram: the
    work?ow has been developed by an intimate collaboration between end-user (in this case, HR personnel) and the
    software engineer implementing the back-end of the work?ow (model, variables, processes etc). A rudimentary
    approach might be encapsulated in the phrase `if you can draw the process on a white-board, a work?ow can be
    created for it'.
    For the software engineer, BPMN provides the (non-exhaustive) functionality shown in table
    . The usual
    process for developing a new work?ow is:
    ? Design application pages (web front-end) for `look and feel' with end user;
    ? De?ne the data model;
    ? Create the process de?nition (work?ow diagrams, variables, contracts, actors etc);
    ? De?ne the process forms;

    Table 1. BPMN Functionality
    human, service (automated) or call activities (sub-processes)
    start, end, messages, timers, error (handlers) and signals
    parallel ( AND ), exclusive ( XOR ), inclusive
    Sequence Flow
    conditional ?ows, default ?ows
    Special Behaviors looping, nesting, transaction, compensation and correlation
    swim lanes, annotation links
    a variety of communications mechanism are supported
    simulation using dummy data is built into the work?ow engine paradigm
    ? Use simulated data to debug and test the work?ow;
    ? Deploy the work?ow on a suitable platform.
    Although work?ows can be started from speci?c event timers (cf. cron ), it is important to understand that
    work?ows are, inherently, asynchronous by design. They may be started at any time from any legitimate and
    authorized source. Multiple work?ows can be active concurrently. This is, clearly, an attractive idea for LSST
    in which the main and auxiliary telescopes may be operating independently but|with singular access to shared
    resources (e.g., the camera, the telescope) also required|a suitable exclusive access mechanism would have to
    be provided for some use-cases.
    Further, it can be argued that the work?ow system is best leveraged throughout the observatory and not just
    in speci?c applications. Consider the OCS Maintenance component: a work?ow would be ideal for querying a
    database periodically to discover the cycle-count on a speci?c part and automatically create, and schedule, the
    purchase requisition when 80% of the MTBF has elapsed: a quintessentially Kanban approach.
    In ?gure
    , we show a sequence diagram, from the current LSST model, of a standard visit with a ?lter change.
    This sequence diagram shows both commands and events associated with the minutiae of control for performing
    a single use-case. The important aspect of this diagram is that it is static (i.e., not executable) but used to
    verify the model and provide documentation on what the software engineer needs to enable.
    , shows a work?ow of a similar operational sequence. Here, the swim lanes map to principal sub-
    systems of LSST but the transition between such lanes is entirely transparent. The work?ow engine provides
    the synchronization between di?erent subsystems e.g., at `Gateway1' which waits for both the data management
    control system (DMCS) and camera control system (CCS) to return. Details of the events produced during this
    sequence are encapsulated and not shown within the activity boxes (`Set Rotator to 0 Degrees', `Change Filter',
    `Move Telescope To Target' etc). This produces a clarity regarding the scienti?c or engineering objective of the
    work?ow. Dummy data can be provided to the work?ow for simulation and to debug the data model without
    impacting any ongoing operations.
    Moreover, note that the work?ow diagram contains two use-cases simultaneously|a ?lter change and no
    ?lter change|and is executable in the (real-time) Bonita BPM Engine. For the astronomer, the web interface
    shown in ?gure
    provides all the relevant inputs and the work?ow would be initiated by clicking on the Submit
    Certainly, using a work?ow system|prima facie|has potential but there are concerns regarding the, naturally
    simpli?ed, examples and real world use-cases (which may require special activities) and how that impacts the end

    Figure 2. Enterprise Architect sequence diagram for a standard visit with a ?lter change. In this diagram we see command
    and event ?ows across the subsystems. The data ?ows that map onto the ?gure
    work?ow diagram are `next visit info'
    and `image nimg exptime shut cond guid cond wfs cond'.
    result. We note that the BPMN standard covers ˘ 500 pages and 98 elements suggesting a lot more complexity has
    been found in practice. If a large number of these elements are required to perform modest tasks in observatory
    operations, the learning curve for new sta? might be considerable.
    There is a more speci?c concern when it comes to the requirement on the OCS layer not to add overhead to
    the observing paradigm. This implies that we might have to look at using persistent objects to represent the
    camera, telescope etc and ways to communicate with these objects would have to be developed.
    A further concern is that we may be on the bleeding-edge of new technology for astronomical use. Certainly,
    the authors know of no other telescope that is considering this approach for controls.
    The next steps for our evaluation are:
    1. Connect the work?ow system to the SAL layer (probably using a custom connector) and to evaluate the
    handling of commands, telemetry and events in and out of a work?ow;
    2. Evaluate the overhead with persistent and dynamic objects;

    Figure 3. Work?ow diagram for a standard visit with and without a ?lter change in Bonita Studio. In this diagram,
    the essence of the work?ow is captured with detailed commands, telemetry and events being subsumed by the activities
    allowing greater clarity regarding the use of the work?ow.
    3. Model a typical work?ow connected with the observing strategy;
    4. Export a use-case model out of one system (using XML) and import it into another to evaluate transfer-
    ability between di?erent products without loss of work;
    5. Evaluate non-BPMN engines such as Taverna which is an Apache Incubator product.
    6. Evaluate the construction timeline implications of adopting this approach.
    Given an a priori observing strategy for running the survey, part of what we would want to achieve is to automate
    implementing that as much as possible, whilst documenting it properly, and this paradigm would seem capable
    of doing it (whereas a scripting solution would struggle with the documentation). So, if the above path?nder
    exercise is successful, the work?ow system would be a serious candidate for an observatory supervisory control
    This material is based upon work supported in part by the National Science Foundation through Cooperative
    Agreement 1258333 managed by the Association of Universities for Research in Astronomy (AURA), and the

    Figure 4. Web interface for a work?ow standard visit using Bonita UI Designer. This UI is developed using purely
    web-driven technologies and the data presented to the work?ow by the run-time engine when the work?ow is started.
    This is, in e?ect, the front end to the work?ow of ?gure
    Department of Energy under Contract No. DE-AC02-76SF00515 with the SLAC National Accelerator Labora-
    tory. Additional LSST funding comes from private donations, grants to universities, and in-kind support from
    LSSTC institutional members.
    [1] Kahn, S., \Final Design of the Large Synoptic Survey Telescope," in [Ground-based and Airborne Telescopes
    VI], Hall, H. J., Gilmozzi, R., and Marshall, H. K., eds., Proc. SPIE 9906 , in press (2016).
    [2] Kurita, N. et al., \Large Synoptic Survey Telescope camera design and construction," in [Advances in Optical
    and Mechanical Technologies for Telescopes and Instrumentation], Navarro, R. and Burge, J. H., eds., Proc.
    SPIE 9912 , in press (2016).
    [3] Daly, P. N. and Schumacher, G., \LSST OCS status and plans," in [Software and Cyberinfrastructure for
    Astronomy], Chiozzi, G. and Guzman, J. C., eds., Proc. SPIE 9913 , in press (2016).
    [4] Mills, D., \LSST communications middleware implementation," in [Ground-based and Airborne Telescopes
    VI], Hall, H. J., Gilmozzi, R., and Marshall, H. K., eds., Proc. SPIE 9906 , in press (2016).
    [5] Ruiz, J. E. et al., \AstroTaverna-Building work?ows with Virtual Observatory services," Astronomy and
    Computing 7 , 3{11 (2014).
    [6] Hook, R. et al., \ESO Re?ex: A Graphical Work?ow Engine for Astronomical Data Reduction," ESO
    Messenger 131 , 42{44 (2008).
    [7] \Business Process Model and Notation," Object Management Group (2011).
    [8] Faura, M. V. et al., \The Ultimate Guide to BPMN2," BPM Library eBook 280116 , 24 (2016).

    Back to top