[Moims-mp] [MOIMS-MP] Request / Activity lifecycle

[Zlobin, Veniamin]

Hello,

Sending my comments regarding Request and Activity lifecycle discussion on May 5.

It is important to communicate that Request contains Activity specification, the motivation for that was repetitions. Therefore Activity instances get created after receiving the request, and currently the first suitable state is 'Activity.Planned'. Now suppose a request contains two activities, A is planned, B rejected. Is there a state to represent B? It is safer to define more Activity states, allowing flexibility for system to define its Activity lifecycle. I see the transitions outside the scope, or at most as suggestion.

In the Autonomy App we chose to preserve the Activity ID in re-planning cycle. The reason was that this facilitates the on-board autonomy demonstration in the Consumer Test Tool, which displays TakeImage activity status history. Otherwise I support new activity instance ID for re-planning. In our case we would have needed an extra layer that matches the new (re-planned) TakeImage activity ID to the original. The implementation decision came from requirements, that's why cutting corners.

Request lifecycle implies the Planning Request node needs to monitor activity execution. Upon receiving activity statuses, it publishes Request.Executing and Request.Completed. Is the semantics system defined, e.g. Request is Executing when A started executing. Now A finished, B hasn't started. What is the Request status now? Aside from dependency on Execution it gets complicated here as well.

Regards,

Veniamin

Veniamin Zlobin
Arhitekt | Software Architect
AS CGI Eesti | CGI
Sõbra 54, Tartu 50106 | Estonia
Tel: +372 53404507
[cid:image001.jpg at 01CFA6BA.A02BD9F0]
CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.
[environment-logo-email]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20200506/7cfa4d32/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1211 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20200506/7cfa4d32/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 649 bytes
Desc: image002.gif
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20200506/7cfa4d32/attachment.gif>