[Moims-sc] [MOIMS-SC] Packet Service Concept - capabilities of PUS-C
Churlaud Olivier
Olivier.Churlaud at cnes.fr
Fri Nov 4 16:33:41 UTC 2022
Dear Peter,
Thank you for your email. I’ll try to draft something and respond to everyone with it.
Concerning the concept of groups, it was defined in the previous version of our M&C and we decided to remove it as it was adding complexity and raising issues of “you are storing things from the consumer on the provider side”. I think it’s safer to do small steps first and add the ‘group’ feature if needed in the future.
Best regards
Olivier
De : MOIMS-SC <moims-sc-bounces at mailman.ccsds.org> De la part de Peter Collins via MOIMS-SC
Envoyé : dimanche 23 octobre 2022 13:31
À : moims-sc at mailman.ccsds.org
Objet : [Moims-sc] [MOIMS-SC] Packet Service Concept - capabilities of PUS-C
Hi all,
It was very nice to finally see some of you in person last week in Toulouse! I hope we can do the same again next Spring.
As promised, attached is a summarised list of the capabilities of PUS-C concerning the packet service concept aka PUS Service 3 (I added an “ID” column just for ease of reference, this has no link to the PUS sub-service assignments). Hopefully it’s useful for Olivier and Serge in particular. I’ve tried to put it in terms of what the consumer can request (via actions) and what the provider can return, to link it to the terminology we’re using within SM&C. Of course if there are any questions then just reach out and we can schedule a call to chat if needed.
Note that there is an additional concept in PUS Service 3 that I haven’t included for now since I thought it was maybe too much to include for this ‘first pass’ we’re making right now. That is the concept of “functional groups” where by the consumer can create groups of packets belonging to a particular (functional) ID, and for each packet within that group define it’s default generation frequency. The point being that then a user can more easily enable these groups of packets to be provided at their default frequency via a more simple action (‘enable functional ID x/y/x’) , rather than going packet by packet to enable individually.
As I said, I thought this was maybe a next level thing we could think about for later and focus on the ‘core’ actions for now (also considering one reason for this is to limit the space/ground comms, but in our case we’re focussing on ground/ground anyway). But of course I can add it if you think useful. In a nutshell though a consumer can create/delete/modify/apply the functional groups and the provider will return the relevant packets at the defined periodicities.
Thanks,
Pete
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>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20221104/b6132d9b/attachment.htm>
More information about the MOIMS-SC
mailing list