[Sea-sa] [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Shames, Peter M (312B)
peter.m.shames at jpl.nasa.gov
Fri Apr 26 17:26:52 UTC 2019
Dear Mario,
We clearly have a difference of opinion about how to interpret the charters and the London Agreement. As a result I think we must bring this to the CESG for further discussion. See below.
Regards, Peter
From: Mario Merri <Mario.Merri at esa.int>
Date: Friday, April 26, 2019 at 9:19 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Brigitte Behal <brigitte.behal at cnes.fr>, Dan Smith <danford.s.smith at nasa.gov>, Erik Barkley <erik.j.barkley at jpl.nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Sam Cooper <sam at brightascension.com>, Scott Burleigh <scott.c.burleigh at jpl.nasa.gov>, SEA-SA <sea-sa at mailman.ccsds.org>
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Dear Peter,
I have read your note and I summarise my conclusions as follows:
1) It is confirmed that your original claim that the SM&C WG is improperly and unexpectedly expanding to on-board is false. It is in the WG charter, it has been since day one.
A charter that says " E2E space-ground MO services via encapsulation/SLE tunneling, including mission planning and scheduling" does not include scope for proposing to take over responsibility for a whole host of real-time, on-board, mission critical functions on the spacecraft. Your most recent incursions included on-board power and data management. Your Oct 2016 materials (attached) show "Mission MO Services" including AOCS, Power, Thermal, Mode Mgmt, and FDIR. These are, by all normal measures, spacecraft on-board real-time functions, SOIS territory, and no "MO functions". That chart on pg 3 is prefixed by a chart that says this:
* High frequency control loops need to be implemented onboard
* Consequently MOIMS has always foreseen implementing services onboard as shown in the following chart 3
I believe that this is flawed logic, since there is no part of the second item that can be technically justified by the first observation. This is a situation where, while it might be possible to consider it in the scope of "what's possible", there is no good technical justification for proposing it. It is possible, but it does not make sense.
2) Because of its nature, mission operations are end-to-end. As such they must work with other more "local" areas of CCSDS. It is not a surprise that we have interfaces and discussion with many more other areas than others.
Working with "other more "local" areas of CCSDS" is not the same as continually pushing to take over aspects of their areas of work. SEA, as I am sure you are aware, has a scope that intentionally provides oversight for all of CCSDS and we have a record of working in concert with other areas. We have never had to take over their areas in order to accomplish this. And we have, in fact, a track record of working cooperatively with other areas.
3) Indeed, space is not a particularly forgiving place. For exactly this reason we propose to standardise on common way of doing the same things in mission operations. I fully respect the opinion of your experts, but please let them know that in Europe we have been doing this since 20 years with the PUS and it works.
Your PUS is an example of standardizing a space packet format used to send control information and return data from on-board activities. It is not in any way the same as proposing a heavyweight and complicated on-board framework for running all of the on-board applications. We at JPL do something like PUS ourselves, as do GSFC and JSC. This is convenient, and useful, but not mandatory. And this approach of sending commands and returning data, without requiring any other integration, allows the on-board, real-time, concerns of managing the spacecraft and its scant resources to be addressed by suitable software that is extremely well designed, well tested, and tailored for the rigors of a real-time, reliable, redundant, fault-tolerant, robust operating environment. In this case you are proposing that this framework, which was designed for the ground, should be adopted in space when it has none of these features.
In conclusion, the perimeter of the MO Services includes space. It is a waste of everyone's time to re-open the discussion every 6 months. You may not like it, but once decided by the CCSDS you should accept it and work with the brief provided by our agencies.
In conclusion, the reason why this comes up frequently is that you keep bringing it up by insisting on unilaterally trying to expand the bounds of your area. Instead of just working within the bounds of your WGs and Area you continually mount what can politely be described as challenges to other areas. That is a key part of what I documented in my last note. If you would cease and desist in this behavior, and stick with agreed boundaries, we would not have to discuss this situation over and over again.
Regards,
__Mario
Regards, Peter
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To: "Mario.Merri at esa.int" <Mario.Merri at esa.int>
Cc: Dan Smith <danford.s.smith at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Sam Cooper <sam at brightascension.com>, SEA-SA <sea-sa at mailman.ccsds.org>, "brigitte.behal at cnes.fr" <brigitte.behal at cnes.fr>, "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>, "Burleigh, Scott C (312B)" <scott.c.burleigh at jpl.nasa.gov>
Date: 18/04/2019 20:15
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
________________________________
Dear Mario,
I have had to take the time to step back from your note for a moment and to look at the bigger picture. There are many threads to pull on, but let me start with the most obvious, that of the so called "London Agreement". You seem to have been saying that the London Agreement gives the MOIMS carte blanche to push MOIMS, especially SM&C, into the spacecraft on-board environment. In point of fact the "London Agreement", as documented on pg 9 of the attached file "CESG-Report-to-CMC-Fall14-Items attentionCMC", is all about curtailing your attempt to force MOIMS SM&C into the CSS Area. It says nothing about supporting a MOIMS SM&C incursion into the SOIS Area. That slide 9 is titled "Agreement to Resolve Cross Support and MOIMS MO Services Overlap". That slide is all about asking MOIMS to honor the existing, and successful, CSS cross support and service management services. It says nothing what-so-ever about MOIMS being given license to expand into the spacecraft on-board domain. That concept seems to be something that you have fabricated in your own mind relative to your memory of the "London Agreement". I think we need to keep the actual agreement, and the background leading to it, in mind.
In actuality, this abbreviated "agreement" that was presented to the CMC was only a small part of the story. Leading up to, and during, those London CESG meetings in 2014 there had been quite a number of discussions about all of the aspects of the rest of CCSDS that MOIMS seemed to be ignoring the existence of. The overlap analysis file that was presented during the 2014 CESG meeting to address this problem is attached. The clear take-away message from that CESG discussion should have been that MOIMS SM&C should be working to harmonize with the rest of CCSDS. It is interesting to observe you used the phrase "support our desire to harmonise across CCSDS standards … for the benefit of CCSDS and our missions". From your behavior it appears that you interpret this to mean that many of the other CCSDS areas should adopt the SM&C framework, and that your path to "harmonization" is that they do things your way. I do not believe that the rest of CCSDS shares this opinion.
This may strike you as an over-blown statement, or an attack. It is not. It's really just a statement of fact. Of all of the areas it is only MOIMS and SM&C that continually pushes into the "territory" of other areas. In all the years I have been in CCSDS I have seen no other areas do that. I note the following specific instances:
· 2018-2019, SOIS: Proposing that SM&C MAL should be used exclusively on-board spacecraft, including for real time functions like power management and data management, and into devices that often have no on-board processing.
· 2014, CSS: proposing that SM&C MAL should be used instead of the CSS service management and cross support services that were already widely deployed or well along in development
· 2014, SIS: proposing that MOIMS SM&C (Mission Operations Service) should be used for SIS DTN Network Management instead of the simple, network-focused approaches already in development
· 2009, SIS: pushing for an analysis of MAL and AMS with the intent of replacing AMS with MAL, a lengthy diversion of effort
· 2005, SOIS: pushing to replace SOIS MTS and AMS with MAL for on-board use, and seeking to claim a piece of the SOIS on-board territory
I have documentation from CESG meeting files and other sources for all of this. I have discussed it with other Area Directors. I have no knowledge of incursions, or attempted incursions, from any other areas of work. All of these were initiated only by MOIMS SM&C. There seems to be a pattern here.
I've not yet addressed the technical aspects of this, but, politics aside, those are also a consideration in determining whether any given effort is likely to result in a good outcome. One way to look at this is from the point of view of architectural approaches, and to ask if there are antecedents that provide any means of forecasting success. There appear to be two fundamentally different technical architecture approaches that can easily be identified. I would characterize the two approaches in this way:
1) Architect the end to end environment around a suite of carefully designed, layered, interoperable protocols. Build applications frameworks on top of that.
2) Architect a malleable, flexible (sic) application or message framework, adopt whatever underlying protocols you can to jig-saw communications together. Use “bridge-ware” to glue all the disparate parts of real systems into a “whole”.
The first of these is the approach that the Internet has taken, and you would have to agree that it is the single most successful distributed technical architecture framework that has ever been created. It has allowed a flourishing community of organizations and users to grow, and it has expanded in quite consistent and sometimes surprising ways to encompass new services and features. The CCSDS areas that develop protocols and interoperable services (SLS, SIS, CSS, and SEA) have followed this model quite successfully.
The second of these is exemplified in my mind by developments such as DCE, CORBA, and JMS. They all took a "framework first" approach and all have in large part failed to gain a significant foothold in distributed system. The only "framework first" approach that I can think of that has succeeded is that of HTTP, HTML, and web services. They are ubiquitous in our world, but they are primarily examples of approach 1, layered, interoperable, protocols.
The next point I feel I must make is that of assessing whether particular approaches are actually appropriate. In the Application and Support Layer (ASL) architecture description we have, as you know, been looking deeply at the MOIMS and SOIS standards, and engaging in the intellectual exercise of trying to make this set of standards and concepts into a sort of "jig saw puzzle" that makes sense. To do that we have had to step back from "what is" and also look at "what might be". Part of the reason for that is that there are pieces of what we understand to be typical mission operations and typical spacecraft systems that are missing. So in the conceptual, abstract, functional viewpoint we have identified functions that are part of typical systems, but for which there are no standards at all. In the MOIMS area these are functions like operations preparation, mission data processing, on-board software management, and spacecraft development and maintenance. Just to be clear, when we describe actual the actual standards, services, protocols, and interfaces we only describe what is, and not what might be, unless there is an identifiable plan in place. And then any of these more speculative topics are carefully labelled [Future] or [Not planned for standardizarion].
We have done the same with the SOIS topics, we want this document to be comprehensive and also even handed. One of the things we have noted is that the MOIMS work tends to be expansive, it conceptually has reached out into territory that it really has no concrete standards for. SOIS, by contrast, has been quite conservative and it only has proposed standards where it thinks that they serve a really useful, identifiable, purpose for interoperability. They even went so far as to abandon some abstract services that had found support from one agency, but which seemed to them to be too advanced, and too abstract, to survive. One consequence of this conservative approach is that SOIS has not even tried to describe the nature of the on-board spacecraft environment, nor the kinds of real-time concerns that are central to developing spacecraft. These are topics like the need for robustness, reliability, redundancy, fault protection, and the real-time management of precious power, thermal, data bandwidth, data storage, and GNC / pointing resources, to say nothing of autonomous fault protection, problem isolation, and robust on-board fault recovery. All of these have been left out of the SOIS discussion, and yet all of these topics are central to designing and developing real spacecraft.
One consequence of this is that all of the diagrams that we in CCSDS have drawn, dating back at least to 2005, that have shown interactions between flight and ground leave out of the picture these key aspects of real systems. This has turned this rich and important set of topics into a sort of "terra incognita", a blank space on the map. Without a deep awareness of the realities of spacecraft design and development it would be easy to think that this is an open field in which to propose new approaches, because "there is nothing there". But there really is a lot there, it just happens to not be described in the CCSDS literature, largely because those who work in the field do not believe that much of it can be standardized. It is too specialized, and too peculiar to each of our "one-off", "built for purpose" spacecraft. We surely will see some sort of "standardization by product line" in specific vendor offerings and in CubeSats, but that is different from "standards" as we tend to use the term. I have attached a revision of a diagram from an ESA EGOS document on which I have drawn in this part of the territory and the rest of CCSDS (except for SEA and security) that was missing from the original. I did not label all of the functions, but I just identified most of them in this paragraph.
All of which brings me to my last point, that of the distinction between what we might imagine to be possible as a sort of intellectual exercise and what makes sense from a very pragmatic point of view. From an intellectual point of view it is possible to posit that a service framework of some sort, designed to work in a terrestrial, resource rich, environment, with chatty protocols, designed for short round-trip times and lots of retransmission opportunities, and ever increasing processor and communications bandwidth can just be expanded into space. The "IP in Space" crew had this sort of flawed logic and it has been shown to be not viable. Intellectually it is possible to posit that the whole SM&C framework, services, protocol bindings, interaction patterns can be successfully expanded into, or even tailored for, the spacecraft on-board environment. I believe that is what led to the suggestion that SM&C could be used to do on-board power and data management, or to suggest that it could be built into any number of different devices on-board that must function in the typical power and resource poor environment.
All of the experts in spacecraft systems that I have talked to over the years, dating back to some of the earliest work I did on SOIS and even its low level services, have rejected these kinds of suggestions. They know just how tightly they have to husband scarce resources and the care that is taken to do so reliably and robustly. To my knowledge most on-board comm interactions tend to be "fire and forget", with lost data noted in the logs, but not recovered except as a separate retrieval operation. Most on-board management of high-speed bulk data from science instruments does not use anything that looks like a file system, instead they end to use carefully designed, reliable, robust, bulk data storage that must be specially managed, accessed, wear leveled, etc. Access is by blocks of memory, not anything like files and directory structures. I'll grant that there are going to be some resource rich missions where some of these constraints do not hold. Some of these may accept a "veneer" of MO services on top of what will still have to be carefully designed, managed, robust, reliable, real-time services and operating systems.
Space is not a particularly forgiving place.
I have to say that I think that CCSDS should be very careful to propose standards and approaches that make real technical sense and to avoid spending effort on things that are intellectually interesting but have little likelihood of being broadly picked up by real space missions. I think that there is a fine line between technology that is truly visionary, like the initial concepts of TCP/IP that spawned the whole Internet-of-Things, and technology that is interesting, but just does not have "legs" or that does not gather the support needed to thrive and survive. DCE and CORBA are examples of technologies that did not stand the test of time. It is not always easy to see these differences ahead of time, but some, like 8-track tapes, were easy to spot. Likewise the choice between TCP/IP and DecNet, SNA, Bitnet, etc.
In seeking harmonization across CCSDS and in working together for the benefit of CCSDS and all of our users we all need to keep this in mind. If, after 15 or more years of effort and proselytizing, standards do not have significant and broad uptake by the community they are intended to serve perhaps they should be abandoned. We see that sort of significant and broad uptake in the case of SLS, SIS, CSS, SEA and even some of the MOIMS in Nav and DAI. SOIS has reinvented itself in a form that looks like it will have legs too, with EDS and DoT, and a focus on interfaces and extensibility from a clearly defined set of core functions.
I'll take a moment to apologize for the length of this note. It went from being a short reply to a sort of an essay. I hope you all understand that this is because I have given a lot of thought to these subjects and not just because of an advanced case of logorrhea.
Best regards, Peter
From: Mario Merri <Mario.Merri at esa.int>
Date: Friday, April 12, 2019 at 2:12 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Dan Smith <danford.s.smith at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Sam Cooper <sam at brightascension.com>, SEA-SA <sea-sa at mailman.ccsds.org>, Brigitte Behal <brigitte.behal at cnes.fr>
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Dear Peter,
It has been 15 years that the MO services are targeted for both ground-ground, space-ground and space-space. There are endless references for this driving design feature, I point you just to the charter of the SM&C WG (https://cwe.ccsds.org/fm/Lists/Charters/DispForm.aspx?ID=26), the published MO Services GB or the "London Agreement". We also have a published binding to SPP to cover the typical space-ground case.
It is both demotivating and disappointing that you question this. As SEA AD I feel that you should be fully aware of our long-standing approach (which we have discussed many times in the past) and instead support our desire to harmonise across CCSDS standards. You cannot continue to put this aspect under discussion. We should all work together for the benefit of CCSDS and our missions.
As for the recent email from Dan, please ignore it as it requires internal discussion.
Regards,
__Mario
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To: Sam Cooper <sam at brightascension.com>, "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, "Mario.Merri at esa.int" <Mario.Merri at esa.int>
Cc: SEA-SA <sea-sa at mailman.ccsds.org>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, Dan Smith <danford.s.smith at nasa.gov>
Date: 10/04/2019 22:16
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
________________________________
Sam, Mario, and Mehran,
Thank you for finally providing these inputs. I have reviewed them and I think I understand where you are coming from and what changes you wish to effect in this SOIS document.
To be completely frank, I think that you are still trying to push what are, in effect, Area Charter changes by what you are proposing. This document was intended to compare the features of the EDS and its “eco-system” and the MAL and its eco-system, at a technical level. You seem to be asking for this document to be turned into a description of why the MO MAL should become the supported on-board environment, and that SOIS and the CCSDS on-board architecture should become fully compliant with the MAL.
I understand that this is your strong desire, but I again have to point out that this is not at all the point of this document, nor is it supported by the charter for your area. In point of fact, I just reviewed that Area Charter again, which is published in the CCSDS Org & Proc Yellow Book, CCSDS A02.1-Y-4, and I do not believe that the Charter, as documented, covers spacecraft on-board services and functions. As stated in the YB, MOIMS covers the operations of spacecraft and the utilization of spacecraft derived data, but makes absolutely no mention of spacecraft on-board applications and services. The spacecraft on-board domain is solely the province of SOIS.
As I said before, if you do wish to propose any such Charter changes the proper place to address that is in the CESG and CMC, and not in edits to this document. That said, this is my opinion and not one that has been reviewed by the SOIS Area, the other members of the SEA SAWG, nor the CESG itself. I am copying this reply to the SEA SAWG and also to the SOIS AD. I expect them to reply for themselves.
If need be this issue, which is in my opinion an attempt to make an Area Charter change, will have to be brought to the CESG for discussion.
Best regards, Peter
From: Sam Cooper <sam at brightascension.com>
Date: Wednesday, April 10, 2019 at 8:51 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, "Mehran.Sarkarati at esa.int" <Mehran.Sarkarati at esa.int>, Mario Merri <Mario.Merri at esa.int>
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Hi Peter,
We've gone through the comments that Mehran, Mario and myself raised and have produced a consolidated output (attached). Where possible we have updated the text rather than just comment as we thought that would be more productive.
What is the plan regarding updating the text in response to the list you and I worked on?
Best regards,
Sam
On 10/04/2019 00:55, Shames, Peter M (312B) wrote:
Mario, Sam, and Mehran,
This document was originally sent in for CESG review on 8 June 2018. The revised version that the SOIS and SEA SAWG agree is adequate and accurate was sent to you on 8 Feb 2019. We believed that we had dispositioned all of the RIDs in a manner that was suitable and appropriate. There were delays. And extensions, and now more delays. It is now two more weeks since I least heard anything.
Please let’s get this wrapped up and out the door. It is, after all, just a Yellow Book report. It is not the UN Charter or a Brexit deal. Let’s get it done so we can all get on to more productive work.
Thanks, Peter
From: Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Date: Thursday, March 28, 2019 at 2:13 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov>, "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>
Cc: Mario Merri <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Hi Peter,
Just to let you know that myself, Mario and Mehran are working to provide a consolidated set of comments in the document.
It should be with you very shortly.
Best regards,
Sam.
On 14/03/2019 21:09, Shames, Peter M (312B) wrote:
Hi Mehran,
Somehow we seem to have a real disconnect between what this document is intended to do, which is to document the features and relationships, such as they are, between SOIS and MOIMS, and what you seem to be trying to do with your requested changes to this document, which is to change the SOIS program of work and to shift CCSDS Area boundaries. Any such changes to Areas, their programs of work, and their interfaces is not handled in this way within CCSDS. It should be handled by some sort of formal request, to the CESG as a whole and then the CMC, to make such changes. This work is being carried out in the present context and not some future one.
In the original round of reviews I very carefully extracted all of the comments from you, Mario, and others who participated, and inserted them into a spreadsheet. That spreadsheet and proposed resolutions was then reviewed with all of the participants from the SEA SAWG, adjusted as needed, and then reviewed with the SOIS and MOIMS stakeholders. I think you got a copy of it a while ago. It has all of the identified issues and all of the proposed resolutions. The final spreadsheet (attached here) was used to drive the edits to the document. It has inputs from you and Mario, inputs from me, and some added notes from the tech editor (KT) I had help me create the final doc. The final edited document was again reviewed by the SAWG and the stakeholders.
With a few exceptions raised by Sam, which have since been resolved, everyone else who has reviewed this document concurs with what it says and is ready to approve it. That includes the SAWG (which includes Roger Thompson and Ray Krosley), the SOIS crew, Sam Cooper, and Richard Melvin. At this point you appear to be the sole dissenter. And, based on your comments, you are dissenting not on the basis of technical issues with what is stated, but apparently based on a desire to change the way that these two areas work and interact. I think that this is an inappropriate way to approach this situation and am asking you to reconsider.
If you do wish to tackle this very different problem of changing the programs of work in SOIS, and shifting the SOIS / MOIMS boundary, I suggest that you do it using the normal CCSDS channels for such requests, i.e. the CESG and CMC. And I ask that you stand-aside and let this document be published in its current form. See A02x1y0c4, Sec 5.1.2, on Consensus:
An individual is responsible for expressing concerns; the group is responsible for resolving them. The group decides whether a concern is legitimate; the individual decides whether to concur with the group, block, or stand aside. All significant issues and their disposition must be documented and accepted by the group.
Are you willing to stand-aside on this matter?
Thanks, Peter
From: "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>
Date: Thursday, March 14, 2019 at 11:26 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov>
Cc: Mario Merri <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Hi Peter,
I have now finally managed to review the commented version by Sam.
I compared it to the comments I had raised on the version from 07. June 2018. I have also attached that version for your reference.
Some of my comments are still not implemented. I put them back in this new version of the document (it is now the third time, I am putting the same comments in the same document). I guess it would be more effective, if the author does not agree with a comment, to leave it in and provide an answer rather than me going back each time and checking if my previously raised comments are or are not implemented.
Some of the comments were implemented through the new text in red (added by Sam?).
My biggest concern is the recommendation part. I think it does make sense to align the API/Interface specification part of EDS with MAL service specification.
At least some effort shall be put in doing it for one concrete device and comparing the two XMLs.
The current document concludes, the scope is different, hence it is ok to leave everything as is and translate from one to other.
I would personally rather see two XML documents defined for one example device (e.g. a star camera with operations such as gotoMode xyz, switch on/off, ...) and a technical assessment if it makes sense or not to align the keywords of MAL and EDS.
My recommendation would be that SOIS EDS remains at hardware interface definition level and delegates the specification of API/Services to be done as on-baord MO Service specifications. For this maybe MAL would need to be extended to also be able to capture the concerns such as timing, etc.
Alternatively the EDS and MAL shall be brought so much in line that the common keywords of the XML schemas are equal for the service/api specification part.
Regards
Mehran
From: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov>
To: "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>
Cc: "Mario.Merri at esa.int"<mailto:Mario.Merri at esa.int> <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Date: 12/03/2019 18:44
Subject: Re: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
________________________________
Hi Mehran.
If it works for you to add your notes to Sam please do so. Maybe that will avoid addressing the same topic twice. I can sort out what we have agreed to already from whatever you add (at least I hope I can AND that it is not too cumbersome).
Please get this to me no later than CoB Thursday, 14 March. This is already long overdue.
Thanks, Peter
From: "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>
Date: Tuesday, March 12, 2019 at 10:01 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov><mailto:peter.m.shames at jpl.nasa.gov>
Cc: Mario Merri <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Subject: [EXTERNAL] Fw: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Hi Peter,
I promised Mario to do a review already last Friday.
I feel very bad, that I didn't manage yet. I will try to do this and send you a feedback this week.
I started to look but it is now a bit difficult. There is the red-lined version that you sent. Then there is the commented version of Sam and loads of email exchange between the two of you.
Would it be ok, if I take the commented version of Sam and add my comments (if any) on top of it?
Regards
Mehran
----- Forwarded by Mehran Sarkarati/esoc/ESA on 12/03/2019 17:54 -----
From: Mario Merri/esoc/ESA
To: "Shames, Peter M (312B)" <Peter.M.Shames at jpl.nasa.gov ><mailto:Peter.M.Shames at jpl.nasa.gov>
Cc: Dan Smith <danford.s.smith at nasa.gov><mailto:danford.s.smith at nasa.gov>, "Rakow, Glenn P. (GSFC-5610)" <glenn.p.rakow at nasa.gov><mailto:glenn.p.rakow at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov><mailto:jonathan.j.wilmot at nasa.gov>, "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>, Richard Melvin <Richard.Melvin at scisys.co.uk><mailto:Richard.Melvin at scisys.co.uk>, Roger Thompson <roger.s.thompson at btinternet.com><mailto:roger.s.thompson at btinternet.com>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Date: 08/03/2019 16:00
Subject: Re: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
________________________________
Hi Peter,
Mehran and/or I will provide you additional comments by the deadline.
Regards,
__Mario
From: "Shames, Peter M (312B)" <Peter.M.Shames at jpl.nasa.gov><mailto:Peter.M.Shames at jpl.nasa.gov>
To: "Mario.Merri at esa.int"<mailto:Mario.Merri at esa.int> <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>
Cc: Dan Smith <danford.s.smith at nasa.gov><mailto:danford.s.smith at nasa.gov>, "Rakow, Glenn P. (GSFC-5610)" <glenn.p.rakow at nasa.gov><mailto:glenn.p.rakow at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov><mailto:jonathan.j.wilmot at nasa.gov>, "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>, Richard Melvin <Richard.Melvin at scisys.co.uk><mailto:Richard.Melvin at scisys.co.uk>, Roger Thompson <roger.s.thompson at btinternet.com><mailto:roger.s.thompson at btinternet.com>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Date: 07/03/2019 19:08
Subject: Re: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
________________________________
Ciao Mario,
I have Sam's inputs and we have identified acceptable resolutions for all of his concerns as of 28 Feb 19.
It's been two weeks since you asked for an extension. Is there any progress on this from your end?
Thanks, Peter
From: Peter Shames <Peter.M.Shames at jpl.nasa.gov><mailto:Peter.M.Shames at jpl.nasa.gov>
Date: Thursday, February 21, 2019 at 5:08 PM
To: Mario Merri <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>
Cc: Dan Smith <danford.s.smith at nasa.gov><mailto:danford.s.smith at nasa.gov>, "Rakow, Glenn P. (GSFC-5610)" <glenn.p.rakow at nasa.gov><mailto:glenn.p.rakow at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov><mailto:jonathan.j.wilmot at nasa.gov>, "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>, Richard Melvin <Richard.Melvin at scisys.co.uk><mailto:Richard.Melvin at scisys.co.uk>, Roger Thompson <roger.s.thompson at btinternet.com><mailto:roger.s.thompson at btinternet.com>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Subject: Re: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Mario,
Ok. Please get response to me no later than 15 March 2019. I really need to get this wrapped up. Meanwhile I will process Sam's inputs, once I have them actually in hand.
Peter
From: Mario Merri <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>
Date: Thursday, February 21, 2019 at 4:19 PM
To: Peter Shames <Peter.M.Shames at jpl.nasa.gov><mailto:Peter.M.Shames at jpl.nasa.gov>
Cc: Dan Smith <danford.s.smith at nasa.gov><mailto:danford.s.smith at nasa.gov>, "Rakow, Glenn P. (GSFC-5610)" <glenn.p.rakow at nasa.gov><mailto:glenn.p.rakow at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov><mailto:jonathan.j.wilmot at nasa.gov>, "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>, Richard Melvin <Richard.Melvin at scisys.co.uk><mailto:Richard.Melvin at scisys.co.uk>, Roger Thompson <roger.s.thompson at btinternet.com><mailto:roger.s.thompson at btinternet.com>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>
Subject: Re: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Peter,
unfortunately please extend the deadline by at least 2 weeks as due to workload we were not able to process this.
Thanks,
__Mario
From: "Shames, Peter M (312B)" <Peter.M.Shames at jpl.nasa.gov><mailto:Peter.M.Shames at jpl.nasa.gov>
To: Mario Merri <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>, "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>, "Roger Thompson" <roger.s.thompson at btinternet.com><mailto:roger.s.thompson at btinternet.com>, Dan Smith <danford.s.smith at nasa.gov><mailto:danford.s.smith at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov><mailto:jonathan.j.wilmot at nasa.gov>, "Rakow, Glenn P. (GSFC-5610)" <glenn.p.rakow at nasa.gov><mailto:glenn.p.rakow at nasa.gov>, Richard Melvin <Richard.Melvin at scisys.co.uk><mailto:Richard.Melvin at scisys.co.uk>
Cc: SEA-SA <sea-sa at mailman.ccsds.org><mailto:sea-sa at mailman.ccsds.org>, "CCSDS Engineering Steering Group - CESG Exec" <cesg at mailman.ccsds.org><mailto:cesg at mailman.ccsds.org>
Date: 20/02/2019 21:45
Subject: Re: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
________________________________
Dear MOIMS & SOIS colleagues,
I requested feedback on this by 22 Feb 2019. Are you going to have replies and feedback by then? I want to get this off my plate.
For those who have lost the thread, this is intended as the resolution for the Condition raised on CESG-P-2018-05-010, see https://public.ccsds.org/polls/Lists/CESGP201805010/AllItems.aspx.
Thanks, Peter
From: Peter Shames <Peter.M.Shames at jpl.nasa.gov><mailto:Peter.M.Shames at jpl.nasa.gov>
Date: Friday, February 8, 2019 at 5:04 PM
To: Mario Merri <Mario.Merri at esa.int><mailto:Mario.Merri at esa.int>, "Mehran.Sarkarati at esa.int"<mailto:Mehran.Sarkarati at esa.int> <Mehran.Sarkarati at esa.int><mailto:Mehran.Sarkarati at esa.int>, Sam Cooper <sam at brightascension.com><mailto:sam at brightascension.com>, Roger Thompson <roger.s.thompson at btinternet.com><mailto:roger.s.thompson at btinternet.com>, Dan Smith <danford.s.smith at nasa.gov><mailto:danford.s.smith at nasa.gov>, "Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov><mailto:jonathan.j.wilmot at nasa.gov>, "Rakow, Glenn P. (GSFC-5610)" <glenn.p.rakow at nasa.gov><mailto:glenn.p.rakow at nasa.gov>, Richard Melvin <Richard.Melvin at scisys.co.uk><mailto:Richard.Melvin at scisys.co.uk>
Cc: SEA-SA <sea-sa at mailman.ccsds.org><mailto:sea-sa at mailman.ccsds.org>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org><mailto:cesg at mailman.ccsds.org>
Subject: SEA SAWG proposed edits to the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets
Dear All,
As reported during the CESG Telecon on 7 Feb 2019, the Systems Engineering Area (SEA), using resources of the Systems Architecture Working Group (SAWG), has completed a review of the SOIS document, CCSDS 870.10-Y-1, MO Services and SOIS Electronic Data Sheets and proposed a set of updates to resolve differences of opinion between SOIS and MOIMS and clarify the relationships. This result was derived using meeting and email discussions within the SAWG and particularly with representatives of the two different points of view (Roger Thompson and Ramon Krosley) and the original author of the document (Richard Melvin). Before sending this document out more widely these parties were polled and they concurred in this release, with two minor issues noted. Those issues have been dealt with in this version.
Three files are attached:
1) A "clean" version with changes accepted, but revised text left in red
2) A raw version with all of the tracked changes visible
3) A spreadsheet extracted from the marked up PDF files, along with the audit trail of discussions leading to resolution
Since this is, in effect, a cross-area "working group" of sorts I would like to ask all of those who have a stake in this to review the document and provide feedback in two weeks, by 22 Feb 2019. I'd like to use a consensus process over email and am hoping we can wrap this up quickly. We will still need to process the final result through the CESG for approval to publish.
Thanks, Peter
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
[attachment "870x10y1 MO and SEDS Yellow Book_bb_chapter 6 updated joint.docx" deleted by Mario Merri/esoc/ESA]
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).[attachment "CESG-Report-to-CMC-Fall14-Items attentionCMC.pptx" deleted by Mario Merri/esoc/ESA] [attachment "Cross Support & MO Service analysis 13Oct14v7.pptx" deleted by Mario Merri/esoc/ESA] [attachment "MOIMS & SOIS from SEA Reference Architecture Plan 27Jul15 v2.pptx" deleted by Mario Merri/esoc/ESA]
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20190426/a0991696/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS SOIS MOIMS v3 Merri 2016.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 787035 bytes
Desc: CCSDS SOIS MOIMS v3 Merri 2016.pptx
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20190426/a0991696/attachment-0001.pptx>
More information about the SEA-SA
mailing list