[Css-rasg] RE: Exomars Reference model

Thu Apr 14 07:06:26 EDT 2011

Peter,

That's not what I mean. I fully understand and strive to reach the
conceptual separation you describe. Implementation independent models
are the core of any proper architecture. It is possible in many
architectural frameworks.

My point is that this separation is inherently impossible in the
Functional Viewpoint (but by no means in architectures in general).
Because the connections shown in the Functional Viewpoint means that the
architectural description always moves into implementation decisions;
who depends on who? The view thus loses its abstraction.

I think the simplest is that I create a classical 'abstract' functional
viewpoint for the operational model. When we agree that the model is
about right, I will change sides and argue why I think it is
implementation specific and thus wrong. It's easier to discuss based on
a real example.

Regards,
Gert.

From: Shames, Peter M (313B) [mailto:peter.m.shames at jpl.nasa.gov] 
Sent: Mittwoch, 13. April 2011 17:08
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

Gert,

They are design / architecture decisions, as opposed to implementation
decisions.  Design is what you are going to do and how you organize the
system to do it.  Implementation is how you create and deploy the parts
that become the operational system.  It's two separate phases.  Almost
all of RASDS is focused upon architecture rather than implementation,
although the Connectivity View and Communications View certainly get
into the topics of where things will be deployed.  But none of this is
about how to implement the system in detail, I.e languages, styles,
code, etc.

I agree that this is part of a continuum, and depending on preference
some people naturally drive toward the implementation end while others
operate at the architecture end or work the process from front to back.

Regards, Peter

From: Gert Villemos <gert.villemos at logica.com>
Date: Wed, 13 Apr 2011 00:37:59 -0700
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, 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: 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

	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. 

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/20110414/9ac00322/attachment.html