[Sls-slp] AOS 5-year review: typo and VCF Service issues
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Wed Oct 28 10:02:57 UTC 2020
John,
my wording yesterday evening was just a late nigh effort :o)
In such sense that verbose splitting had the main task of identifying the
issue.
I do share your main concern "to eliminate any misinterpretation that
there could be only one VCF or MCF service instance per space link"
Considering the original formulation
“The Virtual Channel Frame Service transfers the independently created AOS
Transfer Frames through a space link, possibly together with AOS Transfer
Frames identified by other GVCID values created by the service provider
itself.”
a relatively simple improvement could be the following:
“The Virtual Channel Frame Service transfers the independently created AOS
Transfer Frames through a space link. The existence of a Virtual Channel
Frame Service on a given Virtual Channel does not prevent existence of
other services of the same type or different type on other channels
identified by other GVCID values."
Similarly the sentence in 2.2.3.7 "The Master Channel Frame Service
transfers the independently created AOS Transfer Frames through the
space link, together with AOS Transfer Frames created by the
service provider itself. " could change to
"The Master Channel Frame Service transfers the independently
created AOS Transfer Frames through the space link. The existence
of a Virtual Channel Frame Service on a given Master Channel does not
prevent existence of other services of the same type or different type on
other channels identified by other MCID values. "
I used the formulation "does not prevent" for a sort of alignment to the
MCF/VCF remarks in section 2.2.4 RESTRICTIONS ON SERVICES, i.e.:
b) If the Master Channel Frame Service exists on a Master Channel,
other services shall not exist simultaneously on that Master Channel.
c) If the Virtual Channel Frame Service exists on a Virtual
Channel, other services shall not exist simultaneously on that Virtual
Channel.
but of course also an active form may be used, e.g.:
"Together with a Virtual Channel Frame Service on a given Virtual Channel,
other services of the same type or different type can exist on other
channels identified by other GVCID values."
Finally, as non-native English speaker, I am always open to linguistic
improvement.
Could one of the two proposed shorter texts satisfy the real needs for
improvement?
Best regards
Gian Paolo
From: "John Pietras" <john.pietras at gst.com>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>,
"Kazz, Greg J(US 312B)" <greg.j.kazz at jpl.nasa.gov>
Cc: "Kazz, Greg J\(US 312B\) via SLS-SLP" <sls-slp at mailman.ccsds.org>
Date: 28-10-20 00:06
Subject: Re: [Sls-slp] AOS 5-year review: typo and VCF Service
issues
Sent by: "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>
Gian Paolo,
I was trying to make minimal changes to the existing (new) text, but I
agree with you that trying to squeeze multiple thoughts into a single
sentence is problematic.
My main concern was to eliminate any misinterpretation that there could be
only one VCF or MCF service instance per space link – I’m particularly
sensitive to this point, having just completed the Forward Frame CSTS
book, the main point of which is to allow multiple external (with respect
to the ground station) sources of VC frames to share the same space link,
where each FF-CSTS instance has its own dedicated VC and therefore maps
into a separate instance of the VCF service.
I think that your wording is an improvement on my proposal. In any case, I
would be happy with any wording that makes clear that there can possibly
be:
- one or more instances of the VCF service (each with its own GVCID);
- one or more instances of MCF Service (each with its own MCID, where
multiple MCs on the same space link are valid);
- one or more VCs (each with its own GVCID) generated by the service
provider itself; and/or
- one or more MCs (each with its own MCID) generated by the service
provider itself
[NOTE – I believe that MCs that are populated by frames received through
instances of the VC Frame service should be considered to be MCs created
by the provider system, since those frames come into the MC through the
service provider’s VC Mux function]
Best regards,
John
From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of
Gian.Paolo.Calzolari at esa.int
Sent: Tuesday, October 27, 2020 6:31 PM
To: Kazz, Greg J(US 312B) <greg.j.kazz at jpl.nasa.gov>
Cc: Kazz, Greg J (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] AOS 5-year review: typo and VCF Service issues
Dear All,
the typo remark as presented in John's e-mail looks correct (but I
did not check the documents).
For the other remark I am getting more doubts.
The current sentence is not looking correct to me, but I am not sure the
proposed correction is the best one.
As specified in 2.2.4 RESTRICTIONS ON SERVICES bullet c: If the Virtual
Channel Frame Service exists on a Virtual Channel, other services shall
not exist simultaneously on that Virtual Channel.
Let's consider the original sentence: “The Virtual Channel Frame Service
transfers the independently created AOS Transfer Frames through a space
link, possibly together with AOS Transfer Frames identified by other GVCID
values created by the service provider itself.”
If we split it, I read something like this
“The Virtual Channel Frame Service transfers the independently created
AOS Transfer Frames through a space link.
The Virtual Channel Frame Service transfers possibly also AOS Transfer
Frames identified by other GVCID values created by the service provider
itself.”
In other words it looks as the other frames are also transferred by the
VCF Service while they are transferred by other services (or service
instances) on other VCs/MCs.
The same issue rises also with the rewording proposed by John.
A possible improvement could then be something like this:
“Each Virtual Channel Frame Service instance transfers the independently
created AOS Transfer Frames through a space link.
Those AOS Transfer Frames are possibly multiplexed on the space link
together with other AOS Transfer Frames identified by different GVCID/MCID
values.
These other AOS Transfer Frames can have been created by other VCF/MCF
Service instances and/or by the service provider itself.”
I understand this is likely not to be the best formulation, but may be a
good starting point for a less ambiguous formulation.
I also guess that a similar improvement should apply to 2.2.3.7 for the
sentence "The Master Channel Frame Service transfers the independently
created AOS Transfer Frames through the space link, together with AOS
Transfer Frames created by the service provider itself." noting that <If
the Master Channel Frame Service exists on a Master Channel, other
services shall not exist simultaneously on that Master Channel.>.
Best regards
Gian Paolo
From: "Kazz, Greg J\(US 312B\) via SLS-SLP" <
sls-slp at mailman.ccsds.org>
To: "Kazz, Greg J (US 312B) via SLS-SLP" <sls-slp at mailman.ccsds.org
>
Date: 27-10-20 22:53
Subject: [Sls-slp] FW: [EXTERNAL] RE: Updated TM & AOS 5-year
review files from SLP WG meeting Oct 27
Sent by: "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>
Dear SLP WG members,
John Pietras has what I believe are some good points below.
Please let me know your opinion of his proposed changes below
Thanks!
Greg
Chair SLP WG
From: John Pietras <john.pietras at gst.com>
Date: Tuesday, October 27, 2020 at 2:23 PM
To: "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>
Subject: [EXTERNAL] RE: Updated TM & AOS 5-year review files from SLP WG
meeting Oct 27
Dear Greg and all,
I’ve taken a quick look at the updates TM and AOS books and I found a typo
and a statement that I think is misleading.
First the typo – As modified, the first sentence of the second paragraph
under 2.2.3.6 of the AOS book now reads “For a given service instance,
only one user, identified with the GVCID of the Virtual Channel, and each
VCF Service instance on a physical channel must utilize a unique GVCID
value.” The phrase “can use this service on a Virtual Channel” has been
erroneously deleted.
The sentence should read “For a given service instance, only one user,
identified with the GVCID of the Virtual Channel, can use this service on
a Virtual Channel, and each VCF Service instance on a physical channel
must utilize a unique GVCID value.”
What I believe to be a misleading statement appears in two forms in both
the AOS and TM books. The first sentence of the third paragraph under
2.2.3.6 of the AOS book now reads “The Virtual Channel Frame Service
transfers the independently created AOS Transfer Frames through a space
link, possibly together with AOS Transfer Frames identified by other GVCID
values created by the service provider itself.”
My interpretation of this sentence is that there can be only one instance
of the VCF Service per space link, with the implication that all other VCs
on the space link are generated “by the service provider itself”.
I believe that a more accurate, less ambiguous statement is
“Each Virtual Channel Frame Service instance transfers the independently
created AOS Transfer Frames through a space link, possibly together with
AOS Transfer Frames identified by other GVCID values created by users of
other VCF Service instances, users of Master Channel Frame service
instances (see 2.2.3.7), and/or by the service provider itself.”
If my suggestion is accepted, the same change should be applied to 2.2.3.6
of the TM book.
The analogous situation applies to the MCF Service. The equivalent
modification would be to change first sentence of the third paragraph
under 2.2.3.7 of the AOS book (and 2.2.9 of the TM book) to read “Each
Master Channel Frame Service instance transfers the independently created
AOS Transfer Frames through the space link, possibly together with AOS
Transfer Frames identified by other MCID values created by users of other
MCF Service instances or by the service provider itself.“
Best regards,
John
From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of
Kazz, Greg J (US 312B) via SLS-SLP
Sent: Tuesday, October 27, 2020 12:43 PM
To: Kazz, Greg J (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Updated TM & AOS 5-year review files from SLP WG
meeting Oct 27
Dear SLP WG,
Attached please find two files as a result of the 5-year review:
1. Updated 132.0-B TM SDLP book modified during our SLP WG meeting
today on Oct 27.
2. Updated 732.0-B AOS SDLP book modified during our SLP WG meeting
today on Oct 27.
When I have a chance, I will load both of them to the SLP WG CWE directory
under the Fall 2020 meeting.
Best regards,
Greg Kazz
Principal Engineer
Technical Group Supervisor,
PSSE/EEISE/PPSE (312B)
Jet Propulsion Laboratory
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov
_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp
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).
_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp
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/sls-slp/attachments/20201028/35075587/attachment-0001.htm>
More information about the SLS-SLP
mailing list