Using model based systems engineering for the development of the
Large Synoptic Survey Telescope’s
operational plan
Brian M. Selvy
*a
, Charles Claver
a,
Beth Willman
a,b
, Don Petravick
c
, Margaret Johnson
c
, Kevin Reil
d
,
Stuart Marshall
d
, Sandrine Thomas
a
, Paul Lotz
a
, German Schumacher
e
, Kian-Tat Lim
d,
Tim Jenness
a
,
Suzanne Jacoby
a
, Ben Emmons
a
, Tim Axelrod
a,b
a
Large Synoptic Survey Telescope, 950 N. Cherry Avenue, Tucson, AZ, USA 85719;
b
Steward Observatory, 933 North Cherry Avenue, Tucson, AZ 85721
c
National Center for Supercomputing Applications, University of Illinois at Urbana-Champaign, IL;
d
SLAC National Laboratory, Menlo Park, CA, USA;
e
Large Synoptic Survey Telescope, La Serena, Chile.
ABSTRACT
We
†
provide an overview of the Model Based Systems Engineering (MBSE) language, tool, and methodology being
used in our development of the Operational Plan for Large Synoptic Survey Telescope (LSST) operations.
LSST’s
Systems Engineering (SE) team is using a model-based approach to operational plan development to: 1) capture the top-
down stakeholders’ needs and functional allocations defining the scope, required tasks, and personnel needed for
operations, and 2) capture the bottom-up operations and maintenance activities required to conduct the LSST survey
across its distributed operations sites for the full ten year survey duration. To accomplish these complimentary goals and
ensure that they result in self-consistent results, we have developed a holistic approach using the Sparx Enterprise
Architect modeling tool and Systems Modeling Language (SysML). This approach utilizes SysML Use Cases, Actors,
associated relationships, and Activity Diagrams to document and refine all of the major operations and maintenance
activities that will be required to successfully operate the observatory and meet stakeholder expectations. We have
developed several customized extensions of the SysML language including the creation of a custom stereotyped Use
Case element with unique tagged values, as well as unique association connectors and Actor stereotypes. We
demonstrate this customized MBSE methodology enables us to define: 1) the rolls each human Actor must take on to
successfully carry out the activities associated with the Use Cases; 2) the skills each Actor must possess; 3) the
functional allocation of all required stakeholder activities and Use Cases to organizational entities tasked with carrying
them out; and 4) the organization structure required to successfully execute the operational survey. Our approach allows
for continual refinement utilizing the systems engineering spiral method to expose finer levels of detail as necessary.
For example, the bottom-up, Use Case-driven approach will be deployed in the future to develop the detailed work
procedures required to successfully execute each operational activity.
Keywords:
MBSE, SysML, Systems Engineering, OpsCon, Operational Concept, ConOps, Concept of Operations,
Operational Plan
1. INTRODUCTION
The Large Synoptic Survey Telescope’s (LSST)
1
Systems Engineering (SE) team continues to expand the use of Model
Based Systems Engineering (MBSE) methods to cover more Systems Engineering domains and work products as the
project progresses. Building upon our previous
2,3,12
and ongoing
4
work, the team has now developed a methodology for
capturing a detailed Operational Plan in an MBSE environment. The team is utilizing the
Object Management Group’s
(OMG) Systems Modeling Language (SysML)
5
and Sparx’s Enterprise Architect tool
6
. The methodology builds upon
standard Systems Engineering processes, as defined by the International Council on Systems Engineering (INCOSE)
7
*
bselvy@lsst.org
†
In this paper, “we” refers to the subset of the LSST Technical Operations
Working Group (TOWG) that does SysML
modeling in the Enterprise Architect tool.
and, in particular, the work of Alistair Cockburn in defining a fully specified Use Case
8
. In order to meet the needs of
the LSST project, the extensible nature of SysML was utilized to customize and expand the language where needed.
This paper describes the integrated MBSE methodology developed by the LSST SE team to
capture LSST’s operational
plans, describes the purpose and application of a common Actor Library, and reviews the current status of this model-
based operations planning work.
2. BACKGROUND
This section describes the purpose of both an Operational Concept (OpsCon) and Concept of Operations in the various
phases of a project’s lifecycle as well as some background
on the working groups formed within LSST to support their
development.
2.1 Purpose of a ConOps vs. an OpsCon
INCOSE distinguishes between a Concept of Operations (ConOps) and an Operational Concept (OpsCon). These terms
are often used interchangeably, but from a Systems Engineering perspective, there are distinct differences. In order to
precisely define what this paper is discussing, we begin with some definitions:
Concept of Operations (ConOps)
–
A document at the organization level that addresses the
leadership’s
intended way of operating the organization.
Operational Concept (OpsCon
)
–
A document that describes what the system will do (not how it will do it)
and why (rationale). An OpsCon is a user-oriented document that describes the system from the
user’s
viewpoint. The OpsCon document is used to communicate overall quantitative and qualitative system
characteristics to the acquirer, user, supplier and other organizational elements
7
. This is what the LSST SE
team
calls the “
Initial OpsCon
.”
LSST SE
has defined a third document, which we are calling the “Detailed OpsCon”.
Detailed Operational Concept (OpsCon)
–
A technical document that describes how the system will conduct
its operational mission and defines the resources required to successfully execute the mission.
Collectively, the above documents comprise the scope of what we are calling an Operational Plan.
Figure 1 shows the timing of the development of each of these documents with respect to the traditional Systems
Engineering Vee model, standard life cycle stages, and LSST projects.
Figure 1.
The Development of OpsCons and ConOps in the Context of the System’s Life Cycle
Typically in the very early stages of a project, an initial OpsCon document is written to support the definition of high
level requirements. The purpose of doing so is to develop a concept of how the system will be utilized by end users in
its operational environment. The document provides an operational context for the team developing, refining, allocating,
and deriving the functional, performance, architectural, physical, and
–ility
(quality, reliability, manufacturability,
maintainability, etc.) requirements of the system. This document, after it is written, usually becomes a historical artifact
of the project. In the context of LSST, there was substantial attention given to extracting stakeholder (science
community) needs, deriving science requirements from the needs, and developing a system architecture that is capable of
fulfilling multiple science needs simultaneously. While a traditional OpsCon document was not developed on LSST, the
collective set of science needs, documented in the LSST Science Requirements Document
9
and LSST Science Book
10
can be thought of as stakeholder-defined Use Cases that must be met simultaneously, hence defining the content of an
initial OpsCon but just in a different format.
As the project matures past the Final Design stage and enters Fabrication and Build, detailed plans can now be
developed for how the system as a whole must be operated and maintained as well as the resources (internal project
staff; external stakeholders such as science users, Education and Public Outreach users, and funding agencies; capital;
and equipment) that are necessary to successfully execute the mission. These Detailed Operational Concepts will
continually evolve until the start of operations. The primary audience for these plans will be LSST itself, and they will
ultimately be delivered to the Operations Team. These Detailed Operational Concepts will complement a higher level,
Concept of Operations document that will communicate the overarching operations plan, including governance,
facilities, resources needed, and key operational activities. The Concept of Operations document is aimed for both
internal and external audiences, including funding agencies, operations partners, and other external stakeholders.
The Concept of Operations and Detailed Operational Concept must be mutually consistent. Together, they collectively
define the blueprint of how LSST Operations will be implemented organizationally and technically.
2.2 Technical Operations Working Group (TOWG) Work
LSST recognized the need to begin the technical planning for operations in early 2014 and formed the Technical
Operations Working Group (TOWG). The TOWG’s membership consists of individuals representing Systems
Engineering and each subsystem. The TOWG’s charter is:
The purpose of the Technical Operations Working Group (TOWG) is to discuss, define and review the overall
goals, scope, organization, and implementation methodology for the LSST Technical Operations. The TOWG
will develop the LSST Technical Operations concepts by defining and documenting the Use Cases, activities,
sequences, procedures and resources needed for nominal technical and scientific operations, routine
maintenance, and key repair tasks needed for the 10-year operational survey to meet science requirements.
The TOWG's work will include analysis of allocations for unscheduled downtime; development of approaches
to resolving system failures; and review of estimates for all Actors involved... It is expected that the TOWG will
work throughout the entire construction and commissioning period of the Project.
The TOWG held its first meeting in May 2014. The TOWG meets typically on a biweekly basis and has developed
approximately 500 Use Cases and over 100 Actors that must interact with these Use Cases in order for them to be
successfully executed.
The TOWG’s mission
is well aligned with the development of a Detailed OpsCon.
The TOWG’s technical work
complements and supports the top-down operations planning conducted by other members of the LSST team. This top-
down planning focuses on the concepts necessary to prepare an operations proposal, such as the high-level
organizational structure, key operational work packages, and staffing.
2.3 A Common Model to Support Multiple Objectives
As mentioned previously
3
, the LSST project was an early adopter of Model Based Systems Engineering (MBSE) due to
its inherent advantages over the traditional document-based approach. Using the MBSE approach does not change the
activities that the systems engineers perform or the deliverables produced; however, the documents are no longer the
primary artifacts. As summarized
by Delligatti: “With the MBSE approach, the primary artifact of those activities is an
integrated, coherent, and consistent system model, created by using a dedicated systems modeling tool. All other
artifacts are secondary
–
automatically generated from
the system model using that same modeling tool.”
11
With an
MBSE approach, each design decision is captured as one element in the model
–
sometimes referred to as
one fact in one
place
. The return on investment for MBSE is apparent when changes to elements are made; an element only needs to be
updated once in the model, and that change is automatically propagated throughout to the model to all diagrams where
that element appears. When a change is made in the traditional, document-based approach, the Systems Engineer has to
determine all documents that require updating and then manually update all of them, which costs time and can lead to
errors.
LSST’s
SE team is
developing a modeling methodology to incorporate the work into the team’s larger LSST System
Architecture (SysArch) model
12
as another view
–
the
Operations View
. Over time, the modeling methodology has been
expanded to integrate the technical bottom-up
Detailed OpsCon modeling of the TOWG with LSST’s top-down
ConOps
development. This expansion brings the benefit of having an integrated top-to-bottom model that can be used to check
for consistency and conduct relational analyses. Figure 2 shows that a well-architected single model can serve multiple
purposes and customers.
Figure 2. An Integrated Operations Planning Model Can Be Architected to Serve Multiple Purposes
Taking the longer view, this model is also envisioned as the source of routine operations and maintenance procedures
delivered to the LSST Operations Project.
3. THE LSST MBSE OPERATIONS PLANNING METHODOLOGY
Figure 3 shows an overview of the dual roles of the top-down and bottom-up (TOWG) approaches in LSST’s Operations
Planning methodology. These approaches lead to the development of functional requirements and high level stakeholder
Use Cases at the highest level and the development of detailed activity diagrams with actions allocated to Actors at the
lowest level. Applying MBSE techniques when integrating the results of these two planning approaches maintains
traceability throughout the decomposition/composition analysis cycles and allows for the application of a common set of
Actors (i.e. an Actor Library) across the entire top-to-bottom model.
The TOWG started with developing “Lower Level Use Cases.”
Members of the TOWG worked with subject matter
experts to identify and document what is required to operate major elements of the LSST system during normal
operations (i.e. what types of standard inspections and planning work is required), what types of maintenance activities
are required and on what intervals, what the response should be when there are unexpected failures (i.e. incident
response), and which individuals (Actors) are required in each scenario to successfully carry out the work. From there,
the team recursively decomposed the Use Cases to the point where each Use Case was specifically focused on an activity
that could be performed by a discrete number of Actors. At that point, Structured Scenarios (see Section 0 for more
details) were created, and from those, Activity Diagrams (see section 3.8 for more details) were developed. In cases
where the sending and receiving of messages was deemed important, Sequence Diagrams were utilized. At the time of
the writing of this paper, this level of detail has been completed for approximately 10-20% of all Use Cases in the model.
Figure 3. A Metamodel Overview of the LSST Operations Planning MBSE Methodology
As individuals were identified and associated with Use Cases, they were placed into an Actor Library. The purpose of
defining an Actor Library was to maintain a consistent set of Actors that could be reused as the model evolved and to
reduce the likelihood that
modelers wouldn’t create duplicate
Actors with overlapping purpose with ones already
created.
Other members of the LSST team began by utilizing a more experiential, top down approach. This team began by
defining very high level operational goals and objectives and by looking at how other observatories are organized. As
these high level goals and objectives were developed, they were captured in the model as “High Level Use Cases”.
Additionally, these team members developed a Work Breakdown Structure (WBS) as a means of defining the work to be
performed and the organizational group performing the work in operations. As the WBS was developed, it was also
captured in the model. Members of the Project Systems Engineering team suggested doing functional decomposition as
a means of bridging the Use Case and Organizational domains within the model and ensuring alignment of both with the
WBS. The types of Actors developed by these team members were also cross checked against the existing Actor
Library, and the library was updated as needed.
As all of these various levels and domains of the
Operations View
were developed, associations/connections between the
levels and domains were also generated to maintain traceability and check for consistency.
The next several sections of this paper describe the model in more detail, walking through the model from a top-down
perspective.
3.1 High Level Use Cases
From the Use Case perspective, the model starts with a master Use Case from which all other Use Cases are derived and
traced. Figure 4 (left) shows this master Use Case called “Execute LSST Operations” as well as the system boundary
and broader domain in which LSST operates. The Actors shown are aggregate Actors that represent the entire class of
human or organization Actors falling within their scope.
Figure 4. The Top Two Levels of LSST Use Cases
Figure 4 (right) shows the next level of Use Cases which are traced to the master Use Case. These four second level Use
Cases (Provide Oversight, Perform a 10-year Survey, Enable Science and Analysis of LSST Data Products, and Enable
Education and Public Outreach with LSST Data) are associated with the next level of decomposed aggregate Actors.
This approach of recursive decomposition is then continued within the model, achieving additional levels of specificity
and precision at each lower level.
3.2 Domain Model
–
Identify System Boundaries and Stakeholders
The LSST Operations Project can itself be thought of as a system that must be designed as optimally as possible. After
determining the high level Use Cases and requirements, the system architecture must be developed. A first step is
explicitly defining the system boundary to show what is external to the system vs. internal to the system. In SysML, the
typical means of defining the system boundary is with a domain block on a block definition diagram. The domain block
contains the external environment and the system of interest. Figure 5 shows this context diagram.
Figure 5. The LSST Operations Project Domain
This diagram shows the context within which the LSST System must operate, including defining the external
stakeholders and external environment. Internal to the system are the internal stakeholders (i.e. the project staff), the
project organization (departments), and the functions that must be performed (top level functional decomposition). In
addition, this diagram shows how the highest level functions have been allocated to departments (shown as blue boxes),
and how these functions and departments map to the terminology that many stakeholders are familiar with:
Capturing
the Sky
,
Delivering the Sky to Users
, and
Taking Care of Business
.
3.3 Functional Flow Diagrams
In parallel with the functional decomposition, we also modeled how the highest level functions interact with each other
as a system. Conducting this analysis helps with define the functional system architecture and identify necessary
interfaces and interactions between operational departments. Figure 6 shows the top level information flows diagram.
The top level information flows diagram was modeled in SysML as an Internal Block Diagram (IBD). The outer
rectangle labelled “ibd [Block] LSST [Top Level Flows]” represents the boundary of
the LSST Operations system.
Within the LSST system boundary, the operational project’s main functions are
shown and are the same elements in the
model as shown in previous diagrams: 1) Operate Observatory & Collect Data, 2) Plan, Optimize & Support Survey
Science, 3) Process Data, 4) Archive & Serve Data, and 5) Educate the Public. External to the LSST system are
environments and stakeholders that interact with and impact the operational system. These external elements include the
Astronomical Sky and Cerro Pachón Summit Environment (i.e. environmental boundary conditions on the system and its
performance), the LSST governance Consortium (AURA representing NSF, SLAC representing DOE, and LSST
Corporation representing the foreign partners); and the end data users (the General Public, EPO Users, and Science
Users). The dashed lines with arrows represent the flow of information between internal functional processes or the flow
of information between an external element and an LSST system function.
Figure 6. Top Level Information Flows Diagram
An example of how to follow this diagram: Science Users will provide feedback to the project on Science Performance
based on the analyses and results from the previous data release and/or event alert streams from the LSST system. That
stakeholder input is ingested by the Plan, Optimize & Support Survey Science function and combined with additional
Science and Technical evaluation input obtained from the Process Data function to update the Scheduler Parameters.
The updated Scheduler Parameters are then fed to the Operate Observatory & Collect Data function. The updated
scheduler parameters affect the data collected (raw pixels, calibration data, engineering data, and environmental data)
and sent to the Archive & Serve Data and the Process Data functions. Those data are processed by the Process Data
function to generate the Level 1, Level 2, Science Data Quality Assessment (SDQA)
14
, and Calibration data products
that get transferred to the Archive & Serve Data function. The Archive & Serve Data function then makes the data
products available to external users via the LSST User Interfaces. Science Users then obtain the data through this
interface and conduct their own analysis and research, the results of which can be fed back to the project through the
Level 3 data products interface, and the cycle will repeat.
3.4 Functional Decomposition
After the high level functions have been defined, the functions are further decomposed and allocated to specific
operational groups responsible for their successful execution.
Figure 7 shows an example of the functional
decomposition that has been allocated to the Data Processing and Products Group.
Figure 7. One implementation example of a Functional Decomposition. This example shows a possible partial
Functional Decomposition and allocation to the Data Processing & Products Group
In this example, two top level functions (“Process Data” and “Archive and Serve Data”) are
decomposed into lower level
functions (“Level 1 Services” through “Miscellaneous Services”) which are then still decomposed further. By
conducting this functional decomposition and then allocating the functions to groups, it makes explicit the work which
must be performed by each group and serves as another check against the scope of the experientially-based WBS.
3.5 Lower Level Use Cases
As mentioned previously, lower level Use Cases were identified and developed by discussions with subject matter
experts. They capture events that must occur within the operations project to execute nominal operations, maintenance
operations, and incident response. Figure 8 shows an example of a lower level Use Case diagram, showing several
related Use Cases, their interactions, their associated Actors, and the roles in which the Actors interact with the Use
Cases (Section 4.2 describes these interactions in more detail).
Figure 8. An example of a detailed Use Case diagram. This Use Case covers the planning of daily work activities at
the summit facility.
In this example, the “Plan Daily Work Activities” Use Case, used
to decide on the priority, sequence, and assignment of
nominal and maintenance work activities to
Summit Facility staff during the day shift, includes the “Hold ‘Plan of the
Day’” Use Case where all staff gather to discuss the activities, which includes the “Hold Daily Safety Briefing” Use
Case where the job hazard analyses are reviewed for each task and staff sign off on acknowledgement of the hazards and
the understanding of the mitigations. This diagram also shows the staff members (internal Actors) that interact with each
Use Case, including the role that they play in the Use Case.
3.6 LSST Use Case Customizations
As the TOWG began its work, a natural question arose regarding what types of information should be captured in a Use
Case and, subsequently, what constitutes a fully defined Use Case. To answer these questions, members of the LSST SE
team conducted some research on these topics.
Use Cases are the “externally visible services that a system provides,”
11
where “external” is relative to the frame of reference (for example, for a lower level
Use Case that is the responsibility of
an LSST Operations Project Group, external would mean visible to the other Groups within the project and not
necessarily visible to the external stakeholders). Alistair Cockburn describes a Use Case as, “a contract between the
stakeholders of a system about its behavior.”
8
Mr. Cockburn goes on to describe the elements that should be documented
in any Use Case, which can be traced back to the 1960s and Ivar Jacobson who was working on telephony systems. The
LSST SE team evaluated each of these elements and tailored the set
to the project’s needs. Figure
9 shows these
elements and how they were tailored.
Figure 9.
LSST’s Tailoring of Use Case Elements
In general,
LSST followed the guidance laid out in “Writing Effective Use Cases”; however,
we felt it important to also
capture the frequency and duration where it can be reasonably be estimated, as this information will be valuable in the
future when developing a resource loaded schedule for operations.
Furthermore, SysML distinguishes between
definitions of a “Primary Actor” and a “Secondary Actor.”
A primary Actor
initiates the interaction, or alternatively, can be thought of as invoking the Use Case. A secondary Actor participates in
the Use Case. However, the language does not actually offer a means of visually distinguishing between the two on a
Use Case Diagram. The LSST Project felt that it was important to be able to visibly distinguish between the two.
While the current SysML specification does not include the Use Case customizations and means to distinguish between
primary and secondary Actors that the LSST project desired, the SysML language is extensible and allows for extensions
and customizations. Taking advantage of this feature of the language, the LSST SE team developed an extension of
“Use Case” which we call “LSST Use Case”. The “LSST Use Case” stereotype we developed contains tagged values
and pointers to locations where each item in the “LSST Need’s” column in Figure
9 can be documented. To visually
distinguish an LSST Use Case from a baseline SysML Use Case, a custom shape script was also incorporated, which
includes an outer darker blue oval (see Figure 8 for examples). Additionally, we developed a custom connector which is
an extension of the “association” connector
that we stereotyped as
<<invokes>>
that is used to connect a primary Actor
to a Use Case. Additionally, we created a custom shape script for this element as well, which is distinguished by an
open circle at the Actor end and an open triangle at the Use Case end (see Figure 7 for examples). In the LSST
methodology, all Primary Actors are distinguished by the
<<invokes>>
stereotyped connector; all Secondary Actors are
denoted by the usage of the standard association connector.
Table 1 further defines each of the elements from the
“LSST Needs” column in Figure 9.
Table 1. Description of LSST’s Fully Defined Use Case and Implementation Schema. Rows in Blue are items that
are contained within the LSST Use Case. Rows in Yellow are Actor Elements associated with the Use Case. Rows in
Green are Issue Elements in the model. R/O stands for “Required/Optional”.
Field Name
Description
R/O
Use Case Name
The name of the Use Case. This must be a verb phrase.
R
Responsible Department
the entity that owns (provides the use case (for example, the name of an
organization, system, subsystem, or component)
O
Primary Actor
The actor that invokes the use case (the actor whose goal the use case
represents)
R
Supporting (Secondary)
Actor(s)
The actors that provide a service to the system (participate in the use case by
performing actions)
O
Preconditions
The conditions that must be true for this use case to begin. This is usually the
State in which the system must be in.
O
Guarantees
(postconditions)
The conditions that must be true at the end of the use case
O
Trigger
The event that gets the use case started
R
Main Success Scenario
The scenario (the sequence of steps) in which nothing goes wrong
R
Extensions (alternate
branches)
Alternative sequences of steps branching off of the main success scenario
O
Duration
The time required to complete the "Main Success Scenario" of the Use Case.
R
Duration Units
Units of the Duration specified above.
R
Frequency
How often the Use Case occurs.
R
Frequency Units
Units of the Frequency specified above.
R
Open Questions
Any additional questions or details that must be resolved to fully define this
Use Case.
O
3.7 Structured Scenarios
The typical next level of detail after fully defining a Use Case is to develop an Activity Diagram, which is a dynamic
view of an element that expresses sequences of behaviors and event occurrences over time. The Enterprise Architect tool
has a useful intermediary called a Structured Specification that allows the user to define a set of sequenced actions and
branch actions within the context of the Use Case element. The tool is then capable of automatically generating a basic
Activity diagram from this logic. LSST has utilized this feature extensively as a structured means of developing the
content for activity diagrams. Figure 10 shows an example of a structured specification that was generated for the
“Remove/Replace Shutter” Use Case.
Figure 10. From LSST Use Case to Structured Scenario
for “Remove/Replace Shutter” Use Case
3.8 Activity Diagrams and Actor Allocations
As basic Activity Diagrams as developed from Structured Specifications, they are then further refined to show precise
constraints; flows of matter, energy, or data; decision points and merges; and parallel activities. Activity partitions (i.e.
“swimlanes”) are also added to the diagram and associated with Actors from the Actor library. As activities are dragged
into a swimlane, they are associated with the corresponding Actor in the underlying database; this is equivalent to
drawing another diagram and defining an
<<allocate>>
relationship between the activity/action and the Actor. The
advantage to this approach is that each Actor is then associated with specific activities/actions which he/she is required
to perform. The underlying database can then be queried for a complete list of activity assignments and can be used to
help inform the job descriptions, qualification requirements, and training requirements for Actors. Additionally, it can
be used as a qualitative assessment to review the number of Full Time Equivalents (FTEs) specified for each job
description. We have also found that this process acts as a valuable consistency check of the previous Use Case-Actor
interactions defined on the Use Case diagram, as the process of specifying the more detailed procedure will many times
result in the identification of additional needed Actors not previously identified; conversely, sometimes it is realized that
Actors identified initially as interacting with a Use Case are actually not needed after detailing out all of the activities
and actions. Figure 11
shows the detailed Activity Diagram associated with the “Remove/Replace Shutter” Use Case
which contains activity allocations to specific Actors.
Figure 11.
“Remove/Replace Shutter” Activity Diagram with Actors Assigned to Actions
4. ACTOR LIBRARY
4.1 Actor Library Metamodel
The primary purpose of having a common Actor library is to ensure that there is indeed a single Actor representing each
unique job profile and to avoid the common modeling problem of having multiple objects in a model representing the
same thing. In addition to this basic model management goal, we also have additional goals that can be achieved
through a well architected Actor library:
Define the types of relationships each Actor can have with associated Use Cases
Capture all skills and qualifications required by Actors to successfully execute their associates Use Cases
o
Develop “job descriptions” for each unique Actor based on these inherited skills and qualifications
Document Full Time Equivalent (FTE) counts generated from the top-down approach and qualitatively assessed
through the bottom up approach
Associate Actors with their assigned departments
Determine lines of reporting
Associate Actors with their assigned sites (home institution and physical location), smaller working teams, and
shifts
Figure 12 shows a diagram of the Actor library metamodel that allows us to achieve all of the above goals.
Figure 12. Actor Library Metamodel
The central element in the Actor Library is the
<<human>>
stereotyped Actor. Human Actors represent staff positions
that are required to fulfill the operational mission of LSST. Human Actors can be thought of as unique job descriptions,
and each Human Actor can have multiplicity greater than 1 which equates to having multiple FTEs. Human Actors
inherit a set of required attributes from their associated Role Actors and Skillset Actors. The complete set of required
attributes constitutes the minimum job qualifications for each staff position. An example of a Human Actor would be
“Mechanical Engineer”, and there could be more than
one Mechanical Engineer on the project.
A
<<role>>
Actor
is not an Actor that is always “occupied” or filled by a human. It represents a temporary role that is
only fulfilled by a
<<human>>
Actor when required by its associated Use Case(s). Typically, a pool of <<human>>
Actors are associated with a role so that only one of them needs to fulfill the role when required and allows for rotation.
An example of a
<<role>>
is Crane Operator, which could be fulfilled by a variety of technicians and observing
specialists. Roles typically require special training and impose additional qualifications upon the
<<human>>
Actors
that fulfill them. Attributes, such as specific training, defined within the
<<role>>
Actor are inherited by the
<<human>>
Actors associated with them via the
<<generalization>>
connector.
A
<<skillset>>
Actor is an abstraction that owns skills which are common to a set of human Actors, allowing for all
associated
<<human>>
Actors to inherit the common attributes. For example, all Engineers must have, at a minimum,
a 4 year Bachelor of Science degree in an engineering field. A
<<skillset>>
Engineer Actor with that attribute will then
pass that qualification on to all engineers associated with that Actor via the
<<generalization>>
connector.
To show lines of reporting, a custom stereotype has been defined for the Reference Association called
<<reports to>>.
The numbers at each end of a connector denote the
multiplicity
. For example, each individual
<<human>>
Actor can
report to 1 Manager. Each Manager can have 1 or more direct reports.
In addition to developing job descriptions through inherited skills and qualifications,
<<human>>
Actors are associated
with WBS blocks in order to show which Actors will conduct the work defined through the top-down definition process.
In parallel, lines of reporting are developed for the entire operations project, starting with the LSST Operations Office
and going on down through each of the operational departments. Developing these sets of relationships ensures that it is
clearly defined as to which Actors will conduct and be responsible for which work and will be valuable when doing
model analysis and evaluating consistency between the top down WBS approach and the bottom up detailed Use Case
approach.
As the process continues and decisions are made on which institutions and sites will be responsible for WBS work
packages, Actors will also be assigned to respective sites. Furthermore,
<<shift>>
Actors will be defined where is it
important to distinguish between various work shifts, such as at the summit facility where there are around the clock
operations staffed by multiple work shifts.
<<Group>>
Actors have been defined to represent collections of
<<human>>
Actors that are associated to achieve a
common goal. A group may be comprised of human Actors across multiple departments and can even include external
Actors. Examples include the Change Control Board, Risk and Opportunity Review Board, Data Release Board, and
LSST Safety Council.
Finally, in cases where there are multiple FTEs for a specific staff position (i.e. unique human Actor), each individual
may then further specialize in a specific sub-discipline or field. A
<<specialization>>
Actor represents a human Actor
that also has additional expertise in the stated area of specialization. The specialization typically requires additional
experience, training, or education and is represented as additional qualification attributes included at the
<<specialization>>
Actor level. An example is that a need has been identified for multiple
<<human>>
Observatory
Support Scientists, where there are further needs for individuals to specialize in telescope systems, camera systems,
calibration systems, and survey support.
4.2 Custom Actor-Use Case Association Stereotypes
Another key part of the customization process for us was to create additional stereotypes that can be added to the
connections between Actors and Use Cases that describe the type of interaction each Actor has with the Use Case. One
well established method that can be abstracted and applied here is the Responsibility Assignment Matrix (RACI Matrix)
method
13
. RACI stands for Responsible, Accountable, Consulted, and Informed, and defines four clear roles an Actor
can play when interacting with a Use Case or activity. These four roles are defined as:
Responsible:
Those who do the work to achieve the task. There is at least one role with a participation type of
responsible, although others can be delegated to assist in the work required (see also RASCI below for
separately identifying those who participate in a supporting role).
Accountable:
The one ultimately answerable for the correct and thorough completion of the deliverable or
task, and the one who delegates the work to those responsible. In other words, an accountable must sign off
(approve) work that responsible provides. There must be only one accountable specified for each task or
deliverable. A role may be both accountable and responsible.
Consulted:
Those whose opinions are sought, typically subject matter experts; and with whom there is two-
way communication.
Informed:
Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and
with whom there is just one-way communication.
Consistent application of the RACI stereotypes then qualitatively implies the level of involvement of the Actor in the
Use Case. For example, an Actor that is informed does not need to devote as much time as an Actor with the
accountable role for a respective Use Case. Examples of the RACI roles being applied are shown in Figures 8 and 10.
4.3 Example Usages of the Actor Model
LSST now has a fully populated Actor Library that is consistent with the metamodel and has been used to apply Actors
to Use Case, Activity, and WBS interactions. We have utilized the Actor Library to associate Actors with Work
Breakdown Structure work packages to ensure all Actors in the Actor library are associated with work elements
identified through the top-down ConOps development process.
Figure 13 shows an example of one of these diagrams for the Data Products and Processing WBS second level work
packages. In this example, non-project-staffed contracted work is also shown as
<<blocks>>
to ensure that scope is not
missed. Several examples of this are the service contracts and Memorandums of Understanding (MoUs) shown in
(4.5)
Wide Area Networks
. Also identified are a set of human Actors that conduct work on behalf of the Data Products and
Processing group in
(4.3) Chilean Facilities
but from a line reporting perspective do not report to the Data Products and
Processing Department. Pairing the Actor-WBS diagrams and the Actor Line-Reporting diagrams together is valuable in
explicitly denoting particular instances where Actors report to one department for various geographical or institutional
reasons but then may perform some work on behalf of another department.
Figure 13. One possible implementation of an Actor Loaded WBS. This particular example is for the Data
Processing & Products Department. Note that this is just an example and does not constitute a proposed mapping of
Actors to WBS elements.
Figure 14 shows an example of an Actor Organization Chart for the Data Processing and Products Department.
<<Group>>
Actors are used to aggregate
<<human>>
Actors that have similar skillsets, work on related work
packages, and are associated with similar types of Use Cases. Reference Associations with the
<<reports to>>
stereotype are used to show lines of reporting. Dashed Dependency associations are used to show where human Actors
must work closely with other human Actors but do not report to one another. For example, there is a need to maintain a
consistent project-wide application of Information Technology and Communication (ITC). Figure 14 shows that overall
ITC direction is given by the US-based ITC team and coordinated closely with the Chile-based ITC team to maintain
consistency in process and deployment.
Figure 14. One possible implementation of an Actor Organization Chart. This particular example is for the Data
Processing & Products Department. Note that this is just an example and does not constitute a proposed organizational
structure.
5. CONCLUSION
LSST has developed a comprehensive methodology for modeling a detailed Operations Plan, incorporating the scope of
a standard OpsCon and ConOps in a single, integrated model. This approach allows for end-to-end traceability and
consistency checks as well as the ability to apply Actors from a single Actor Library to all aspects of the model structure.
The MBSE approach also has the advantage of providing the project with a living repository to further update the plan as
details evolve and change, with the long term goal of serving as the repository for electronic work procedures for routine
and normal maintenance activities to be delivered to the Operations Project.
The MBSE approach has significant benefits over the traditional, document-based approach once developed and
instantiated. However, the authors note that there is a significant investment required on the part of any project that
decides to implement MBSE. The amount of time required to train staff in both an MBSE tool and language is not
inconsequential. Additionally, staff must learn an existing modeling methodology, develop, or tailor their own.
However, once the investment is made, the long term benefits to the project and broader organization are many, such as
reduced rework, fewer incongruencies, and quicker change cycles.
6. ACKNOWLEDGMENTS
The authors would like to thank all of the members of the Technical Operations Working Group (TOWG) for their
significant contributions in generating the Use Case, Activity Diagram, and Actor content captured in the
Operations
View
of the LSST SysArch MBSE model. The authors would also like to thank this group for providing feedback on the
modeling methodology as it was developed, as this feedback has only helped strengthen the overall approach.
This material is based upon work supported in part by the National Science Foundation through Cooperative Support
Agreement (CSA) Award No. AST-1227061 under Governing Cooperative Agreement 1258333 managed by the
Association of Universities for Research in Astronomy (AURA), and the Department of Energy under Contract No.
DEAC02-76SF00515 with the SLAC National Accelerator Laboratory. Additional LSST funding comes from private
donations, grants to universities, and in-kind support from LSSTC Institutional Members.
REFERENCES
[1]
Kahn, S., “Final design of the Large Synoptic Survey Telescope,” in [Ground-Based
and Airborne Telescopes IV],
Hall, H. J., Gilmozzi, R., and Marshall, H. K., eds., Proc. SPIE 9906, in press (2016).
[2]
Claver, C.F. et al., “Systems engineering in the Large Synoptic Survey Telescope project: an application of model
based systems engineering,” in [Modeling, Systems Engineering, and Project Management for Astronomy VI], Angeli,
G.Z., and Dierickx, P., eds., Proc. SPIE 9150, 91500M (2014).
[3]
Selvy, B. et al, “Using SysML for Verification and Validation Planning on the Large Synoptic Survey
Telescope
(LSST),”
in [Modeling, Systems Engineering, and Project Management for Astronomy VI], Angeli, G.Z., and Dierickx,
P., eds., Proc. SPIE 9150, 91500N (2014).
[4]
Lotz, P. et al, “LSST control software component design,”
in [Software and Cyberinfrastructure for Astronomy IV],
Chiozzi, G., and Guzman, J., eds., Proc. SPIE 9913, in press (2016).
[5]
“OMG
Systems Modeling Language (OMG SysML
TM
) version 1.4,” Object Management Group, September 2015,
http://www.omg.org/spec/SysML/1.4/PDF/ (23 May 2016).
[6]
Sparx Systems, “Enterprise
http://www.sparxsystems.com
(23 May 2016)
[7] Walden, D.D., et al (ed.), [INCOSE Systems Engineering Handbook, Fourth Edition], John Wiley & Sons,
Hoboken, NJ, 1-283
(2015).
[8] Cockburn, A., [Writing Effective Use Cases], Addison-Wesley, Boston, 2-243 (2001).
[9] Ivezic, Z et al, "LSST Science Requirements Document," LSST Project Management Document
LPM-17
(2011).
[10] LSST Science Collaborations and LSST Project, [LSST Science Book, version 2.0], Large Synoptic Survey
Telescope, arXiv:0912.0201 (2009).
[11] Delligatti, L., [SysML Distilled: A Brief Guide to the Systems Modeling Language], Addison-Wesley, Upper
Saddle River, NJ, 3-10 (2014).
[12] Claver, C. F., et al.,
“Using SysML for MBSE Analysis of the LSST System”,
in [Modeling, Systems Engineering,
and Project Management for Astronomy IV], Angeli, G.Z., and Dierickx, P., eds., Proc. SPIE 7738, 77381D (2010).
[13] Understanding Responsibility Assignment Matrix (RACI Matrix).
http://project-management.com/understanding-
responsibility-assignment-matrix-raci-matrix/.
(2 June 2016)
[14] Juric, M. et al., “The LSST Data Management System,” in
[Astronomical Data Analysis Software & Systems
XXV], ASP Conf. Ser. in press, arXiv:1512.07914 (2016).
