<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>AW: ExoMars Architecture update?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Eric,<BR>
<BR>
Thanks for the answer.<BR>
<BR>
There has been a heavy update of the document and its right now being reviewed by ESA. Its some rather fundamental changes, but in my eyes definitly to the better. I hope it will be ready soon for general distribution.<BR>
<BR>
Kind regards and enjoy your weekend,<BR>
Gert.<BR>
<BR>
<BR>
-----Ursprüngliche Nachricht-----<BR>
Von: Barkley, Erik J (317H) [<A HREF="mailto:erik.j.barkley@jpl.nasa.gov">mailto:erik.j.barkley@jpl.nasa.gov</A>]<BR>
Gesendet: Fr 16.09.2011 03:19<BR>
An: Villemos, Gert; Shames, Peter M (313B); Colin.Haddow@esa.int<BR>
Cc: Nestor Peccia; Mario Merri; CCSDS RASG<BR>
Betreff: RE: ExoMars Architecture update?<BR>
<BR>
Hello Gert,<BR>
<BR>
I hope this e-mail finds you doing well. Unfortunately I have been extremely preoccupied with other matters and so have not really had time (not to mention budget) for the Exomars architecture effort.<BR>
<BR>
With regard to point 7, I think that Peter's inclusion of the service management component is okay from the overall architecture point of view as this is indeed something that has to occur. I have no objections to assuming that the management port for the managed components is implicitly -- perhaps some sort of stereotype could be to indicate this for the managed components. I realize that all of this may be somewhat academic at this point as you perhaps may not have any further budget to produce any further updates the document. Which brings me to the main point of writing which is to see if there is an update of the document that is to be made available such that it should be scheduled for some sort of discussion/review at the fall CCSDS meetings beginning in approximately 6 weeks. Any information as to the updated document would be most appreciated.<BR>
<BR>
Best regards,<BR>
<BR>
-Erik<BR>
<BR>
<BR>
From: Villemos, Gert [<A HREF="mailto:gert.villemos@logica.com">mailto:gert.villemos@logica.com</A>]<BR>
Sent: Tuesday, July 19, 2011 12:47 AM<BR>
To: Shames, Peter M (313B); Barkley, Erik J (317H); Colin.Haddow@esa.int<BR>
Cc: Nestor Peccia; Mario Merri; CCSDS RASG<BR>
Subject: RE: ExoMars Architecture update?<BR>
<BR>
One comment more regarding point 7;<BR>
<BR>
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.<BR>
<BR>
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?<BR>
<BR>
Cheers,<BR>
Gert.<BR>
<BR>
<BR>
<BR>
From: Shames, Peter M (313B) [<A HREF="mailto:peter.m.shames@jpl.nasa.gov">mailto:peter.m.shames@jpl.nasa.gov</A>]<BR>
Sent: Mittwoch, 22. Juni 2011 23:30<BR>
To: Villemos, Gert; Barkley, Erik J (317H); Colin.Haddow@esa.int<BR>
Cc: Nestor Peccia; Mario Merri; CCSDS RASG<BR>
Subject: Re: ExoMars Architecture update?<BR>
<BR>
Guys,<BR>
<BR>
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:<BR>
<BR>
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.<BR>
2. Ditto for the "Proximity Link", which is how "space to space links" are usually described<BR>
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.<BR>
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.<BR>
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.<BR>
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.<BR>
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.<BR>
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.<BR>
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.<BR>
I am sure that there is more, but it escapes me right now.<BR>
<BR>
Peter<BR>
<BR>
<BR>
From: Gert Villemos <gert.villemos@logica.com<<A HREF="mailto:gert.villemos@logica.com">mailto:gert.villemos@logica.com</A>>><BR>
Date: Tue, 21 Jun 2011 00:46:33 -0700<BR>
To: Erik Barkley <Erik.J.Barkley@jpl.nasa.gov<<A HREF="mailto:Erik.J.Barkley@jpl.nasa.gov">mailto:Erik.J.Barkley@jpl.nasa.gov</A>>>, "Colin.Haddow@esa.int<<A HREF="mailto:Colin.Haddow@esa.int">mailto:Colin.Haddow@esa.int</A>>" <Colin.Haddow@esa.int<<A HREF="mailto:Colin.Haddow@esa.int">mailto:Colin.Haddow@esa.int</A>>>, Peter Shames <peter.m.shames@jpl.nasa.gov<<A HREF="mailto:peter.m.shames@jpl.nasa.gov">mailto:peter.m.shames@jpl.nasa.gov</A>>><BR>
Cc: Nestor Peccia <Nestor.Peccia@esa.int<<A HREF="mailto:Nestor.Peccia@esa.int">mailto:Nestor.Peccia@esa.int</A>>>, Mario Merri <Mario.Merri@esa.int<<A HREF="mailto:Mario.Merri@esa.int">mailto:Mario.Merri@esa.int</A>>>, CCSDS RASG <CSS-RASG@mailman.ccsds.org<<A HREF="mailto:CSS-RASG@mailman.ccsds.org">mailto:CSS-RASG@mailman.ccsds.org</A>>><BR>
Subject: RE: ExoMars Architecture update?<BR>
<BR>
Hi Eric,<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
Regards,<BR>
Gert.<BR>
<BR>
<BR>
<BR>
<BR>
From: Barkley, Erik J (317H) [<A HREF="mailto:erik.j.barkley@jpl.nasa.gov">mailto:erik.j.barkley@jpl.nasa.gov</A>]<BR>
Sent: Montag, 20. Juni 2011 21:53<BR>
To: Colin.Haddow@esa.int<<A HREF="mailto:Colin.Haddow@esa.int">mailto:Colin.Haddow@esa.int</A>>; Villemos, Gert; Shames, Peter M (313B)<BR>
Cc: 'Nestor.Peccia@esa.int<<A HREF="mailto:'Nestor.Peccia@esa.int">mailto:'Nestor.Peccia@esa.int</A>>'; Mario Merri; CCSDS RASG<BR>
Subject: ExoMars Architecture update?<BR>
<BR>
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.<BR>
<BR>
Best regards,<BR>
<BR>
-Erik<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
</FONT>
</P>
<br clear=all> 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.
</BODY>
</HTML>