[Css-rasg] RE: Exomars Reference model

Wed Apr 13 03:37:59 EDT 2011

I agree and understand the intended abstraction of the functional
viewpoint, the elements of the diagram and the connection to the other
diagrams. 

I however think there is a fundamental discrepancy in the concept of the
viewpoint, as soon as dependencies / connections are shown between
functions. Let me make an example based on one of the diagrams often
shown in connection with the RASDS functional viewpoint (see slide 6 of
http://wodpec2006.telin.nl/presentations/takahiro-yamada-ODPforSpace-wod
pec2006.pdf
<http://wodpec2006.telin.nl/presentations/takahiro-yamada-ODPforSpace-wo
dpec2006.pdf> ). In this diagram;

1.    In the functional viewpoint we show the function 'Monitoring &
Control' and 'Data Repository' as being connected. What if I have
designed a ground segment working only in live, where there is no 'Data
Repository' function? 
2.    Or what about the connection between the 'Data Repository' and the
'Orbit Determination'; what if I have a system where orbit prediction is
done directly from the data received through the 'Data Acquisition'
function and never based on stored data, i.e. in my system the
connection is between 'Orbit Determination' and 'Data Acquisition'?

This simple diagram is full of what I see as implementation decisions,
and implementation decisions should not be part of the functional
viewpoint.

I do not want to discuss whether the diagram is correct or whether the
functions have been fully or correctly identified; it's the concepts I'm
discussing. The conceptual problem demonstrated by this diagram is in my
eyes not a problem of the example, but rooted in the very concept of
trying to model connections between functions in an abstract view. In
any functional diagram like this that pretend to be completely generic
and universally applicable, I will always be able to find scenarios
where it will not be the case.  At best it can be argued that this is
'best practice' or done 'most of the places', but not that it is really
done everywhere. In this case the functional viewpoint is reduced to be
one example of many, which destroys the notion of a common view.

What can be done is;
- Each function can be modelled individually in a generic manner showing
provided interfaces. This is like a service contract specification.
- A 'typical' assembly, or a specific example assembly of a mission, can
then be created using the generic functions showing how it could be
assembled into a complete system.

This is what we have done in the operational reference model.

I find this a very interesting, fundamental discussion in regards to the
usage of the RMODP/RASDS viewpoints. I would suggest that we raise the
question to the RMODP forum. I would be pleased to be corrected in my
understanding, if there is a way of modeling connections between
functions in a generic manner.

Kind Regards,
Gert.

From: Shames, Peter M (313B) [mailto:peter.m.shames at jpl.nasa.gov] 
Sent: Dienstag, 12. April 2011 17:22
To: Villemos, Gert; Barkley, Erik J (317H); CCSDS RASG;
Colin.Haddow at esa.int
Cc: Nestor Peccia; Mario Merri; James, Steven
Subject: Re: Exomars Reference model

Hi Gert,

Nice to have you back in the discussion.  ;-}  Will you be joining us in
Berlin?

I'm going to respond specifically to your comment on the Functional
Viewpoint.   The entire purpose of the Functional Viewpoint is to
address the required functions in a system, their behavior, and the way
that they interact to perform system behavior.  Interfaces are shown as
are connections.  Some sense of allocation to hardware components may be
shown as a correspondence to the Connectivity View, but this is not
required nor is it a part of the Functional View.  There is no
requirement to discuss how these functions are to be implemented either,
they could be hardware, software (of many types), on many different
operating systems.  All of these in RASDS are compressed into the
Connectivity Viewpoint, in RM-ODP they have a separate Engineering
Viewpoint where these implementation issues are addressed.  

Describing how functions are connected is not "implementation", but it
certainly is a part of architecture or system design.

I would agree with your that an EDL scenario might be a Functional
Viewpoint description of the system.  If the focus is on system
functions then this is clearly the case.  In SysML you might use an
activity diagram or a sequence diagram with functional objects
represented to describe this.  If, on the other hand, you were
describing the behaviors of a human organizations in carrying out these
activities then you might use the same modeling approach, but the
objects would be human actors rather than system functions.  RASDS does
not really address human actions, but SysML and UML do, as does DoDAF.
I think that human behaviors map into an Enterprise Viewpoint, and that
you might use activity diagrams or even BPMN, to model this, with humans
as the active objects carrying out the actions.

Cheers, Peter

From: Gert Villemos <gert.villemos at logica.com>
Date: Tue, 12 Apr 2011 01:20:31 -0700
To: Erik Barkley <Erik.J.Barkley at jpl.nasa.gov>, CCSDS RASG
<CSS-RASG at mailman.ccsds.org>, "Colin.Haddow at esa.int"
<Colin.Haddow at esa.int>
Cc: Peter Shames <peter.m.shames at jpl.nasa.gov>, Nestor Peccia
<Nestor.Peccia at esa.int>, Mario Merri <Mario.Merri at esa.int>, "James,
Steven" <steven.james at logica.com>
Subject: RE: Exomars Reference model

	Dear Erik,

	Thank you for your detailed comments.

	Regarding figure 5; I agree that the diagram attempts to show
two things, the functional viewpoint (the objects and their connections)
and the assembly for ExoMars (the packages). It may be a good idea to
have a separate model showing only the functional viewpoint, as RMODP /
RASDS forsees.

	Personally I would argue that a functional viewpoint can never
be completely abstract as RMODP / RASDS forsees, but will always be a
specific example assembly; if a function is defined to depend on another
function, then that is in fact the introduction of an implementation
concerns, as the model assume that the function will always be
implemented using the other function. Which violates the idea behind the
functional viewpoint, as its intended to be an abstract model, and leave
the implementation concerns to the communication viewpoint. By showing
functions depending on other functions, the model therefore in my view
automatically becomes non-abstract. 

	The module naming and the grouping of functions follows the
ExoMars architecture directly. The model is an example assembly for
ExoMars, mapping the ExoMars architecture (the packages) to the
operational functions of the reference model. 

	Regarding the profile used; In the first version of the
document, reviewed by Peter Shames, a description of the profile was
included. It was commented that this should not be in reference model
but either in the RASDS or in the document being prepared by Takahiro. I
agree that's it is important to agree on a (descriptive?) UML profile
for the RASDS and describe its usage in detail to help people understand
the models. The question is where this should be.

	For the reference model we have used the parts of the publically
available RMODP profile that are aligned with RASDS. If / when the RASDS
specific viewpoints gets used, a profile should be created for them.

	Kind regards,
	Gert Villemos.

	From: Barkley, Erik J (317H)
[mailto:erik.j.barkley at jpl.nasa.gov] 
	Sent: Freitag, 1. April 2011 01:57
	To: CCSDS RASG; Colin.Haddow at esa.int
	Cc: Shames, Peter M (313B); Nestor.Peccia at esa.int;
Mario.Merri at esa.int; Villemos, Gert; James, Steven
	Subject: FW: Exomars Reference model

	RASG Colleagues,

	FYI.

	Colin,

	My apologies for not at least acknowledging receipt sooner.
Thanks for sending out the update.

	I have only had time for a very brief scan, but based on that I
have a couple questions.

	Figure 5 is indicated as a functional viewpoint.  But it comes
across to me as a bit of a mix of different concerns. For example, the
labels on the packages all essentially are different
enterprises/administrative domains that are yoked together to provide
the complete system. But one of the packages is labeled "entry, descent
and landing" - this is really not in the same general classification of
functions indicated but rather an activity that is carried out with the
lander.  (Best architectural practices would also suggest that this is
in fact to be a functional view based on the specification of the
viewpoint -- i.e. labeled as functional view.  Ultimately it would be of
benefit to have the formal definition of the viewpoint such that the
reader understands what the criteria for stating a function are in this
diagram - but at this point I'm not really too concerned about these
kind of formalisms. )

	Another question which may just be simply my ignorance, is that
there is a lot of application of the <<CV_Object>> stereotype and I must
admit I do not know nor is there any definition offered as to what the
<<CV_Object>> connotes.  By the same token,
<<CV_OperationInterfaceSignature>> does not really tell me that much
without some identification/definition of what the stereotype implies. 

	I would certainly be willing to support a telecon to discuss
this the week of 11 April or later if that makes sense to you. 

	Best regards,

	-Erik 

	From: Colin.Haddow at esa.int [mailto:Colin.Haddow at esa.int] 
	Sent: Wednesday, March 02, 2011 9:02 AM
	To: Shames, Peter M (313B); Barkley, Erik J (317H);
Nestor.Peccia at esa.int; Mario.Merri at esa.int
	Cc: Gert.Villemos at Logica.com; Steven.James at Logica.com
	Subject: Exomars Reference model

	Dear all, 
	                  please find attached the latest draft of the
ExoMars reference model. I'm afraid this iteration took somewhat longer
than expected. Anyway I look forward to your comments and with a bit of
luck we should be able to get the next revision completed faster. 

	Cheers for now, 

	Colin 

------------------------------------------------------------------------
---------------------------------
	Dr. Colin R. Haddow,
	OPS-GI, European Space Agency,
	European Space Operations Centre,
	Robert-Bosch-Str 5,
	64293 Darmstadt,
	Germany.

	Phone; +49 6151 90 2896
	Fax;      +49 6151 90 3010
	E-Mail;  colin.haddow at esa.int

------------------------------------------------------------------------
---------------------------------

	Think green - keep it on the screen. This e-mail and any
attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be
subject to legal privilege. It should not be copied, disclosed to,
retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and
all copies and inform the sender. Thank you. 

Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-rasg/attachments/20110413/6379a146/attachment-0001.html