[Css-rasg] Re: Exomars Reference model

Tue Apr 12 11:21:35 EDT 2011

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-rasg/attachments/20110412/412f5440/attachment-0001.htm