[Moims-sc] CCSDS MO Green Book update

Thu Apr 20 11:04:06 UTC 2017

Hi Sam,

In the discussions with MO new comers and even with some of the people who 
have been around for a long time, the separation between "MO Framework" 
and concrete "MO Services" has always been a source of confusion.
When people talk about MO, they very often mix the MAL design time 
aspects, its run time aspects, the role of COM and COM services and the 
concrete MO Services on top of the MO Framework as well as their 
relationship to a particular encoding and  binding.

The best example is the discussion we had recently where after performing 
a detailed analysis for a possible implementation, the involved persons 
had missed after reading the standards (apparently they had missed the M&C 
book) the point that "MO" includes also concrete services and is not just 
an abstract framework!

I see that the proposed ToC tackles this in a number of places: "MO 
Operations Technology" chapter as well as in "Mission Operations Design", 
"integrating MO Systems"  and probably to some extent in "Developing MO 
Applications". 
This is good on one side as it is looking into different aspects and can 
provide input for each aspect separately, at the other side the basic 
questions and the big picture could easily get lost, if the information is 
scattered in different sections.

It may be good to have early in the document a short chapter which shall 
not be technical at all and written in a way that can be understood 
without getting too much in the details explaining these concepts. 
Something like

What is MO?
The MO Framework

What is a Generic Service and Data Specification Language good for? (
Design Time role of MAL and COM)
Model Driven Architecture: CIM-PIM-PSM
Implementation and communication independence
Machine Readable specification of interfaces 
Auto Generation of Artefacts
Common Service and Data Meta-Model (common set of meta-data)
Service and Data Taxonomy 
SOA Governance (Service Template, common design patterns and best 
practices for capability specification, ...)
....
Why do we need a Common Object Model and what is it good for? (Common 
Object Model Part of the COM)
Interrelating Objects from different Mission Operation functional contexts 
(e.g. Alert --> Check --> TM Parameter --> Action --> Plan --> Planning 
Request, ...)
Historical View of Mission Operation Entities
Unified handling of the common aspects of objects at service level
Removing Abstraction and getting very concrete (Role Bindings)
Selecting the Implementation Technology: (Explain Language binding and 
what is it good for)
Selecting Communication Technology: (Explain encoding and communication 
binding, at this level I think it is good enough to handle 
encoding/transport as one)
Mission Architecture removes generality by fixing the choices: Deployment 
Architecture, Selection of services and required capabilities, 
optimisation, ...
What does MO Framework provide as added value in terms of functionality 
(why shall I use MO as a framework)
Non-Functional aspects of Mission Operations (Run-time aspects of MAL)
Addressing and Routing of in complex operation deployment architectures 
(where multiple operations entities, ground stations, relay satellites, 
rovers, etc. are involved)
Reliable interaction provided at higher level than communication, e.g. 
when using a non-reliable comms (reliable messaging provided at MAL level, 
ensuring sequence of interaction messages based on selected pattern)
Incorporated Security at application layer (explain how MO Framework 
architecture allows pluging in of security provider elements that would 
allow authorisation at operation level or even content based, for instance 
depending on the value of a parameter of an action) explain the difference 
to communication layer security 
Ensuring Operations Consistency at Application Layer: Explain Transaction 
Management possibilities 
Tractability and Auditing: Explain how the framework provisions means for 
tractability of every invocation (Activity Tracking Service, ...)
Service Level Agreements and Quality of Service
Interoperability: Bridging the disparity in implementation (comms and 
implementation technology)
Reusable Common Functionalities provided by the framework (COM Services 
and COMMON Services + Broker which I believe should be a Service similar 
to other COM Services)
COM and COMMON Services (utilities)
Multi-Casting of information (I think we should seperate the Pub-Sub 
pattern from the generic broker multi-casting functionality/service)

The MO Services 
Standardised Services
Custom Services

The Blue text is for your information only. I added it to illustrate how 
the basic concepts of MAL (Design Time vs Run-time), COM (COM and COM 
Services), Technology Bindings and COMMON Services are captured in a 
non-technical way. The above structure could translate in a more technical 
perspective to 
- MO 
  -MO Framework
    - MAL
       - Design Time
       - Runtime
    -COM
       - Common Object Model
       - COM Services
    - COMMON Services
    - Technology Binding
      - Language Bindings
      - Encoding and Transport bindings
  -MO Services
- Standard Services: M&C, MP&S, MDPDS, ...
- Custom Services

Another point, which I think could be useful to cover in the green book is 
related to the "Operability Requirements" and how they are full-filled by 
MO. At European level this is more formalised by corresponding ECSS 
standard and how it could be mapped to PUS or MO. But more generically I 
think the basic concepts of the Operability Requirements could speak the 
language of the Mission Operators, hence useful for the Green Book.

Last but not least the link to the concepts of the Space System Model 
could be incorporated in the Green Book. Also here at European level we 
have the corresponding ECSS standard. The generic concepts can be useful 
to explain the system context, especially for the M&C services part.

Regards
Mehran

From:   "Sam Cooper" <sam at brightascension.com>
To:     MOIMS-SC at mailman.ccsds.org
Date:   06/04/2017 10:19
Subject:        [Moims-sc] CCSDS MO Green Book update
Sent by:        "MOIMS-SC" <moims-sc-bounces at mailman.ccsds.org>

Dear All,

As discussed during the last teleconference, please find below the outline 
we are proposing for the Green Book update for your comments.

Green Book Skeleton
Introduction (2-3 pages)
Aim of this Green Book
Structure of this Green Book
How to read and use this Green Book
Mission Operations Motivation and Rationale (6-8 pages)
Background and context
Scope under consideration
Challenges facing operations and space systems development
Stakeholder identification
User needs
Role of software, and mission operations services, in addressing the user 
needs
Requirements on MO
Mission Operations Design (4-6 pages)
Terminology
Design principles (e.g. SOA, messaging, at a high-level)
The MO service model (non-technical description)
Providing and consuming services (non-technical description)
Applications and services
Standard services
MO in practice - some example case studies
Mission Operations Technology (4-6 pages)
The MO service model in more detail
Layering in MO
Common services
The role of the common object model
The Message Abstraction Layer
Developing MO Applications (4-6 pages)
Typical MO applications
Relationship between applications and services
Standard vs application-specific services
MO application development tools
...
Integrating MO Systems (4-6 pages)
Essential services
Detailed description of common services and COM services
The role of the MAL and communications protocols
Reference implementations
Implementing an MO system using the reference tools
...
Managing and Administering MO Systems (4-6 pages)
The role of the common services
Audit trail
Archiving
Security
...
MO Communications (4-6 pages)
Detailed look at the architecture and the way communications works
Overview of different communications bindings
...
Overview of the Standards (2-3 pages)
Top level view of the standards/books
Mapping of the standards onto topics and stakeholders
Mapping of the standards/topics/stakeholders onto the following chapters

Stakeholders 
Preliminary list of stakeholders:
Managers 
Mission level
Infrastructure
Programme managers
Operators (Ops)
System Integrators (EGSE and AIT)
Software Developers 
Infrastructure
Applications
Edit this section

Stakeholder to Section Mapping
For Managers:
Read first three sections
Read Managing and Administering MO Systems
If further detail required, read Mission Operations Technology
For Operators:
Read first three sections
Read Mission Operations Technology
If further detail required on management, read Managing and Administering 
MO Systems
If further detail required on development, read Developing MO Applications
For System Integrators:
Read first three sections
Read Mission Operations Technology
Read Integrating MO Systems
If further detail required on management, read Managing and Administering 
MO Systems
If further detail required on development, read Developing MO Applications
For Application Software Developers:
Read first three sections
Read Mission Operations Technology
Read Developing MO Applications
If further detail required on integration, read Integrating MO Systems
If further detail required on management, read Managing and Administering 
MO Systems
For Infrastructure Software Developers
Read first three sections
Read Mission Operations Technology
Read Integrating MO Systems
Read MO Communications
If further detail required on management, read Managing and Administering 
MO Systems
If further detail required on development, read Developing MO Applications

The idea of the book is that it has some general overview sections at the 
beginning and then, depending on your interest, you have a set of sections 
that are applicable to you that you should read. The hope is that these 
later sections can be more focussed and relevant that trying to cover 
everything for everybody which I think the previous document suffered 
from. Also, we are trying to emphasise the goals and uses of MO rather 
than the technology, so putting the horse back in front of the cart.....

So, please, any comments you have on anything, but ideally other 
stakeholders and the sections they would want. If you could send those to 
me by Monday the 24th of April that would be brilliant.

We hope to release a first draft of the document in time for us to discuss 
in San Antonio. It will not be complete and will most likely only cover a 
few sections but should give us an idea of direction and style.

Thanks,
Sam.

_______________________________________________
MOIMS-SC mailing list
MOIMS-SC at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-sc

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20170420/6b4a33d9/attachment.html>