[Css-rasg] RE: Viewpoints and views (further follow up on AI #017)

Wed Mar 17 13:06:25 EST 2010

Erik,

Apologies if I was a little irritable in the telecon.

Some comments/responses below ...

Roger

________________________________

From: Barkley, Erik J (317H) [mailto:erik.j.barkley at jpl.nasa.gov] 
Sent: 17 March 2010 01:11
To: Roger Thompson; CCSDS RA BOF
Subject: Viewpoints and views (further follow up on AI #017)

Roger,

Thank you very much for the inputs. I have finally had a chance to read
through the inputs.  Some comments follow.

I think that we need to consider a bit of formalism with regard to views
and viewpoints.  I think really what you have proposed are viewpoints. 

[RST] You may be correct - I think we need to define what we mean by
Viewpoints and Views if we mean to indicate something different.  I can
go with a Viewpoint being an abstract specification of a View, and I was
trying to stay abstract from the methodology used to capture the Views.

Let me elaborate a bit by saying that I think we could state that
viewpoints are really specifications from which views are then
constructed. Taking a look at the draft concept paper, on page 13, there
is, in a tabular fashion, an attempt to state what the specification
viewpoints are for the various views:

Viewpoint Element

Viewpoint

Enterprise

Functional

Services

Communications

Information

Main concepts

CCSDS Processes & procedures; Policies; Principles; 

Org structure (role, responsibility, function); Charters; 

Members;

Requirements;

Mission models;

Use cases;

Scenarios;

Ops Concepts;

Functional standards (compression, time  correl & exchange);

Security algorithm;

Various APIs (SLE & others); SOIS MTS (API);

Cross support services (sle, csts); CSS SM;

SM&C (Mission ops svcs, common, core);

Info Arch svcs; SOIS abstract svcs;

SANA;

Protocols (rf, range, code, mod, link, network, file/msg, spp, encap);

Space link idents;

Applic Profiles;

OSCP; SM&C (MAL);

CCSDS doc tree;

CCSDS Glossary;

Info exchange stds (nav, XTCE, DEDSL, time code, PVL, SFDU, SM&C COM);

Reference arch / models (RASDS, SLE, CSSA, this doc);

Operational Processes (SCID assign, CA process, OAIS, PAIMAS);

Stakeholders

Concerns

Modeling Techniques

Analysis Methods

Based on this table, you can see that that the functional viewpoint is
essential spec'd (at a conceptual level)  to provide a view encompassing
scenarios, use cases, operational concepts, and more "format oriented"
recommendations.   

[RST] I do have some problems with the detail of what is in the
different views.

I suppose I am trying to identify what we need in order to build a
coherent Reference Architecture model in which the different views are
consistent across the whole RA model.  If we don't do that I think we
will have problems down the line.

Some topics seem to be mis-placed in terms of the viewpoints.

I see the Reference Architecture being an abstract model (Logical model)
that covers everything within the CCSDS space system domain.  I would
rather separate aspects that are to do with the CCSDS standardisation
process domain - and keep this out of the RA model initially.  In terms
of RM-ODP this corresponds to the first 3 views (Enterprise, Functional
and Information) - its then a moot point whether we need additional
"Service" and/or "Communications" views.

The scenarios we have identified would then correspond to specific
deployments of that model (Physical model) that will probably not cover
everything in the Logical model, but indicate how it would be deployed
to support that scenario.  Each scenario may have its own Physical
model(s).  It may be best to consider Deployment a separate viewpoint,
and this is where the Scenarios would fit.

The abstract model needs to identify:

-                      The functional components that together form a
space system (and the interfaces between them)

-                      The organizational or spatial components over
which these functional components need to be deployed (in the deployment
view for a Scenario)

-                      The information that flows across
inter-functional interfaces (including its structure, format)

It also needs to capture

-                      The standards that we define and their
relationships - this may also include identification of "services" or
interface standards.

-                      A communications protocol perspective - this
probably will need different functional views for each layer of the
stack.

Similarly, the services viewpoint then identifies a view consisting of
the "service oriented" recommendations.  

[RST] I think there is a separate topic (not within the Reference
Architecture) associated with the Reference Model for Service Oriented
Specifications.

So, in general, the proposal to have services identified in the
functional view, is, to me, taking a bit too much of "shortcut" by
assuming that we are doing a services architecture, when in fact we
really need to address the whole of CCSDS with the Reference
architecture.  

[RST] All views are inter-connected.  Functions expose Interfaces,
Interfaces carry Information and may represent a Service (defined
pattern of interaction, message exchange and behaviour).  Deployment
views for individual scenarios allocate Functions to
organizational/spatial components, thereby exposing those interfaces
which need to be interoperable.

I do agree very much that there needs to be an expression of the
services inter-relationship, and although we could spec the services
viewpoint to include that in the services view, I think we could  just
as well treat this from the information viewpoint.  

[RST] I don't see this as part of the information viewpoint (unless it
is a data structure/format standard).  It may be part of the
communications viewpoint.  Effectively it specifies expected protocol
stacks, but should allow for flexible deployment at different layers of
the protocol stack.

I look forward to discussing this further at the telecon tomorrow.

Best regards,

-Erik

From: Roger Thompson [mailto:Roger.Thompson at scisys.co.uk] 
Sent: Monday, March 08, 2010 6:31 AM
To: Barkley, Erik J (317H); CCSDS RA BOF
Subject: RE: [Css-rasg] Updated action items

Please find attached the response to Action #017 below.  I apologise for
this being late - I realise that 30 minutes before the telecon doesn't
give much time for review in advance.

The "one or two paragraphs" ran to a few pages - but sadly no diagrams
(partly because I didn't want to get into a debate on which diagramming
standard to use).  I believe this could all be done in UML, which may
have advantages in terms of tool support to ensure a coherent model.

Best regards,

Roger

________________________________

From: css-rasg-bounces at mailman.ccsds.org
[mailto:css-rasg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J
(317H)
Sent: 22 February 2010 23:40
To: CCSDS RA BOF
Subject: [Css-rasg] Updated action items

CCSDS Colleagues,

The updated action item list based on today's telecon has been uploaded
to the CWE and maybe retrieved via

http://cwe.ccsds.org/css/docs/CSS-RASG/CWE%20Private/ActionItems/CCSDS-R
A-BOF-ActionItems-22-Feb-2009.xls

For quick reference the actions from today's telecon are shown below.
Please note that there is a general action to review Leo's synthesis at
scenario identification terms.

Best regards,

-Erik

-----Actions from Today's Telecon----

017

Open

Provide a paragraph or two on concerns, issues of functional vs. service
view.  (Service identified in functional view vs. service view
indicating service relationships)

R. Thompson

22-Feb-10

5-Mar-10

018

Open

Review results of AI 012 (aggregate CCSDS scenarios) and provide
comments as needed

All

22-Feb-10

26-Feb-10

SciSys UK Limited. Registered in England and Wales No. 4373530.

Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.

P Before printing, please think about the environment.

SciSys UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.

* Before printing, please think about the environment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-rasg/attachments/20100317/fa49c203/attachment-0001.htm