[Css-rasg] Re: Exomars Reference model

Wed Apr 13 11:08:25 EDT 2011

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<mailto:gert.villemos at logica.com>>
Date: Wed, 13 Apr 2011 00:37:59 -0700
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>, CCSDS RASG <CSS-RASG at mailman.ccsds.org<mailto:CSS-RASG at mailman.ccsds.org>>, "Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>" <Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>>
Cc: Nestor Peccia <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>, "James, Steven" <steven.james at logica.com<mailto: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-wodpec2006.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<mailto: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<mailto:gert.villemos at logica.com>>
Date: Tue, 12 Apr 2011 01:20:31 -0700
To: Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>, CCSDS RASG <CSS-RASG at mailman.ccsds.org<mailto:CSS-RASG at mailman.ccsds.org>>, "Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>" <Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>>
Cc: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Nestor Peccia <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>, Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>, "James, Steven" <steven.james at logica.com<mailto: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<mailto:Colin.Haddow at esa.int>
Cc: Shames, Peter M (313B); Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>; Mario.Merri at esa.int<mailto: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> [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<mailto:Nestor.Peccia at esa.int>; Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>
Cc: Gert.Villemos at Logica.com<mailto:Gert.Villemos at Logica.com>; Steven.James at Logica.com<mailto: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<mailto: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/cac48f9d/attachment-0001.html