[Css-rasg] RE: ExoMars Architecture update?

Villemos, Gert gert.villemos at logica.com
Tue Jul 19 03:47:28 EDT 2011


One comment more regarding point 7;
 
In principles all services should have a 'Service Management' service as
well, allowing the agreement, configuration, scheduling, etc of the
specific service. I think the 'Cross Support Functional Model' as
defined in RASIG and in the CSTS-RM contains the concept that all
functions have service ports and management ports.
 
Question is whether we want to model the management port explicitly
every time, or whether we say that a (set of) services has an associated
'management service', but doesn't show it to keep the diagram simple?
 
Cheers,
Gert.
 
 
 
From: Shames, Peter M (313B) [mailto:peter.m.shames at jpl.nasa.gov] 
Sent: Mittwoch, 22. Juni 2011 23:30
To: Villemos, Gert; Barkley, Erik J (317H); Colin.Haddow at esa.int
Cc: Nestor Peccia; Mario Merri; CCSDS RASG
Subject: Re: ExoMars Architecture update?
 
Guys,
 
Here are some hacks at the model.  I am sure that I did no lasting
damage, but hopefully the tweaks to the Exomars diagram will help
clarify some things.  I found the following confusing things, but it may
just be how I am reading your intent:
 
1.       A "Space Link" is normally thought of as an RF physical thing.
As such it is not a function, but you may wish to model it as a first
class entity.  It will not have ports such as SLE RAF, and F-CLTU, if
anything it would have only an RF port and attributes such as frequency,
modulation, and pointing.
2.       Ditto for the "Proximity Link", which is how "space to space
links" are usually described
3.       I do not think we need to go into all of the details of how RF
links are created, just to model them at a high enough level to show how
they participate in communications.
4.       I added Space Link Production component (and Proximity too)
since we need to separate the service production from the service
provisioning, which is what SLE actually connects to.
5.       You seem to have SLE bits and pieces scattered all over the
place. The only place they really belong is between the elements in the
OMOC that produce and aggregate frames and the element in the service
provide that accepts them.
6.       I added a Spacecraft Tracking element that would produce
tracking and radiometric data, which what the Flight Dynamics functions
needs to get its job done.
7.       I added a Space Link Management (or Planning) function in the
OMOC, which is what would connect to the Service Management function in
the service provider, using the CCSDS Service Management protocol.  I
showed it connected to SLE as shorthand, since the diagram was getting
rather cluttered.
8.       The DSN, EDL & Rover, OMOC are listed as Organizational
Elements in the Functional View.   But these are also given "ports",
which seems somewhat strange to me.  I think of organizational elements
as being in the Enterprise view.  If they show up in the Functional View
at all it is for purposes of showing ownership.  If you called these
things Facilities I would have less of a problem, or you could call them
Service and Service User Elements.
9.       Everything under "Ports" is called a Service of some type.  I
would think that Service Elements have Ports, which I think is backwards
from how you have it now.  But maybe I misunderstand how you are using
this.
I am sure that there is more, but it escapes me right now.
 
Peter
 
 
From: Gert Villemos <gert.villemos at logica.com>
Date: Tue, 21 Jun 2011 00:46:33 -0700
To: Erik Barkley <Erik.J.Barkley at jpl.nasa.gov>, "Colin.Haddow at esa.int"
<Colin.Haddow at esa.int>, Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Nestor Peccia <Nestor.Peccia at esa.int>, Mario Merri
<Mario.Merri at esa.int>, CCSDS RASG <CSS-RASG at mailman.ccsds.org>
Subject: RE: ExoMars Architecture update?
 
	Hi Eric,
	 
	Peter send some very interesting documentation on methodology
(thanks Peter), but I did not receive any suggestions to update /
addition of functional elements from anyone. We would very much welcome
this input.
	 
	I will update the recommendation with the comments raised at the
meeting that I can correct without input. I will be away next week, so
it will be the 8th of July, not the 20th of June as planned.
	 
	Regards,
	Gert.
	 
	 
	 
	 
	From: Barkley, Erik J (317H)
[mailto:erik.j.barkley at jpl.nasa.gov] 
	Sent: Montag, 20. Juni 2011 21:53
	To: Colin.Haddow at esa.int; Villemos, Gert; Shames, Peter M (313B)
	Cc: 'Nestor.Peccia at esa.int'; Mario Merri; CCSDS RASG
	Subject: ExoMars Architecture update?
	 
	My notes from the Berlin meetings indicate that Gert was to
receive inputs with regard to the function definitions by 10 June. In
particular, Peter had an action item to provide additional functional
inputs by 10 June. I will admit that my e-mail goes by rather fast
sometimes but to the best of my knowledge I don't believe anybody
supplied any inputs?  There was then supposed to be an update with
regard to the ExoMars architecture document so that a teleconference
could be held on 17 June. The general idea was then to produce the
updated document by 30 June. So far I don't think we are doing so good
on this. Does anyone have any updates with regard to their function
definition inputs and/or updates to the ExoMars architecture document?
I suspect we need to do a bit of a rescheduling here.  Status updates
would be much appreciated. Thank you.
	 
	Best regards,
	 
	-Erik
	
	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/20110719/8a037db7/attachment-0001.html


More information about the CSS-RASG mailing list