[Css-csts] FRs specified with the new tool
John Pietras
john.pietras at gst.com
Wed Feb 27 17:02:56 UTC 2019
Dear All,
I know that we have all been off working other issues, and this email may have fallen through the cracks. So I’m just re-sending it in case it’s hard to find otherwise (also, I’m copying the full WG, whereas the distribution of the original was limited to only those directly working on the issues). I am not expecting you to had the chance to read and absorb it in time for tomorrow’s telecon, but I can at least introduce it tomorrow and answer any questions that might come up.
Also, as I noted in the email below, I have split the spreadsheet into separate, FR-specific Word documents (as agreed at the fall meeting), and I have updated the errata sheets for the FRs that Wolfgang updated in December. My original intent was to create a hierarchy of folders in the CWE and post them there after we discussed the higher-level issues that I raised in my email. However, in order to help speed up the process, I have attached a ZIP file with files and the proposed hierarchy. Note that I had the notion (explained below) to preface each of the folders with the last digit of their OIDs in order for the folders to lexicologically sort themselves. However, that is only useful once we have firmly locked down the OIDs. It may be simpler to remove the OID-digit prefixes. When we have decided that the structure, etc., is “good enough”, I can create the proposed folders in the CWE and we can update the errata sheets through those folders.
Looking forward to talking with you tomorrow.
Best regards,
John
From: John Pietras
Sent: Thursday, January 24, 2019 2:18 PM
To: 'wo_._he at t-online.de' <wo_._he at t-online.de>; Holger Dreihahn <Holger.Dreihahn at esa.int>; Pham, Timothy T (3300) <timothy.t.pham at jpl.nasa.gov>
Cc: Wolfgang Hell <whell at gmx.de>
Subject: RE: FRs specified with the new tool
Dear Wolfgang,
My apologies for taking so long to respond to your email – I’ve had a number of personal issues to deal with, and there have been a few unexpected “emergencies” in the SMWG that I have had to deal with.
I have started to look at the details of your updates. I am having difficulty reading the full contents of the file in any “pretty printed” manner since I do not yet have Holger’s tool. I can only see it using a commercial XML editor (XMLspy). I am able to use the XML stylesheet that Holger generated almost 3 years ago (frm.xsl), and while that stylesheet still nicely displays the information that it was set up to display, of course it does not address the new information that has been added, notably the information regarding Functional Resource Sets. In any case, I will need to either install Holger’s updated tool itself or get an updated stylesheet in order to examine the updated FRM XML document beyond what my current stylesheet enables.
One top-level comment is that I noticed that you have re-organized OIDs so that the FRs of the CCSDS 401 Return Physical Channel Reception Functional Resource Set immediately follow the FRs of the CCSDS 401 Forward Physical Channel Transmission Functional Resource Set. Our original “scheme” was to list the baseline forward baseline FRs first, followed by the return baseline FRs. That ordering is still present in the remaining FRs. Do you intend to do more further reorganization of this type – e.g., have the return sync and channel coding FRs immediately follow the forward sync and channel coding FRs? And we have discussed, when we get more FRs in the same stratum – e.g., forward and return 415 space link carrier FRs – we will still have to put those FRs at the end of the sequence.
Looking at the updated file reminded me of the issues involving configuration control of the FRM XML. Will we continue to keep everything in one large XML document? If so, if there are several authors making changes, will we have some sort of “check out” procedure of the master document? Would it be desirable and/or possible to break the document up in some way into smaller XML documents (Functional Resource Sets would seem to be a good unit of “chunking”)? I used the XML INCLUDE feature to a great extent when creating the Blue-1 Service Management schemas – if that is compatible with Holger’s tool that might be an easy approach, although we’d also have to consider whether it would also be compatible with SANA.
For my part, I have converted the single SANA Registry Issues Excel spreadsheet into a family of Word documents as planned, with one document for each functional resource. My plan is to create a set of directories in the CSTSWG CWE space, where each FR type gets its own subdirectory (folder) such that as we address the different issues of a given FR type we can create updated versions of the Word document for that FR. The name of each FR subfolder is the classifier of the FR (e.g., “FCltuTsProvider”). In addition, if we want the folders to sort in order, I could preface the name of the folder with the relative OID number (e.g., “14.FCltuTsProvider”). However, I would only like to do that if we can “lock down” the numbers (see above). [Also if we did that, in the case of the first 9 identifiers, I would a leading “0” (e.g., 01.Antenna”) to ensure that the folders will always appear in their lexicological order.]
In most cases, the names of the FRs in the current database do not conform with the abbreviation standards that Wolfgang and I had come up with, and/or with changes that have evolved in the FR model composition. I have named the subfolders and contained documents to comply with what I think are the correct names with respect to those abbreviation conventions. The following is the list of folder names, and when those names deviate from the classifiers in the XML document the entry is highlighted in red. Before I post these folders to the CWE I would like for us all to agree on what will be the classifiers of the FRs. The changes do not need to be made in the XML file immediately, but I think that we should all be working from a common set of FR classifiers.
Note: In the current draft of the FR RM Tech Note, all classifiers – for FRs, parameter, event, and directives – begin with lower-case letters. This is in contrast with the XML file, in which FR classifiers have upper-case initial letters. However, I kind of like using the initial cap to distinguish the FR classifiers from the others, and I plan to make the change in the Tech Note. So the FR classifiers below are as they will appear in the next release of the Tech Note.
- Antenna
- Fwd401SpaceLinkCarrierXmit
- FwdLinkRanging
- Rtn401SpaceLinkCarrierRcpt
- RtnRangeAndDopplerExtraction
- FwdTcPlopSyncAndChnlEncode – currently listed in the XML file as FwdTcSyncAndChannelEncoding
- FwdFixedLengthFrameSynchChnlEncodeAndOidGen – currently listed in the XML file as FwdAOSSyncAndChannelEncoding. The name changes derive from two sources: (1) Gian Paolo’s comments on the first version of the FF book, in which he pointed out that Unified SLDP frames would use it in addition to AOS frames (and possibly more) and that the “fixed length frame” terminology is a leading candidate for the new name, and (2) the “AndOidGen” part was explicitly added because the corresponding Sync and Channel Coding Blue Book will most likely not include the OID generation function (this is analogous to adding “PLOP” to the TC Sync and Channel Encoding FR.). Note that this name is not necessarily final, as we will want to align it with the Blue Book name when it is finally published, and it might be different. But for now it will deflect “don’t call it AOS” comments.
- TcMcMux - currently listed in the XML file as TCVCMux
- TcVcMux - currently listed in the XML file as TCVCMux
- FwdTcEncapVcPktProcVcGen - currently listed in the XML file as TCEncapVCPktProcessingVCGen
- FwdEncapMapPktProcessing - currently listed in the XML file as EncapMAPPktProcessing
- FwdMapMux - currently listed in the XML file as MAPMux
- FwdAosMcMux - currently listed in the XML file as AOSMCMux
- FwdAosVcMux - currently listed in the XML file as AOSVCMultiplexing
- FwdAosEncapPktProcVcGen - currently listed in the XML file as AOSEncapsulationPacketProcessingAndVCGeneration
- FcltuTsProvider - currently listed in the XML file as FCltuTsProvider
- FwdFrameCstsProvider - currently listed in the XML file as ForwardFrameCSTSProvider
- FspTsProvider - currently listed in the XML file as FSPTSProvider
- CfdpSendEntity - currently listed in the XML file as CFDPSendingEntity (Note – this may be combined with the receiving entity FR, but they are currently separate)
- FwdFileSvcProd - currently listed in the XML file as ForwardFileServer
- FwdFileDataStore - currently listed in the XML file as ForwardFileDataStore
- TgftHost - currently listed in the XML file as CrossSupportFileTransferServiceProvider. The name aligns with the current TGFT terminology
- RtnTmSynchAndChnlDecode - currently listed in the XML file as RtnTmSyncAndDecoding
- RtnMcDemux – currently combined with RtnMcRcpt in the XML file RtnMCDemuxReception
- RtnMcRcpt – currently combined with RtnMcDemux in the XML file RtnMCDemuxReception
- RtnVcDemux – currently combined with RtnVcRcpt in the XML file RtnVCDemuxReception
- RtnVcRcpt – currently combined with RtnVcDemux in the XML file RtnMCDemuxReception
- pktExtractAndDeEncap - currently listed in the XML file as PacketExtractionDeEncapsulation
- FrameDataSink
- OfflineFrameBuffer
- RafTsProvider
- RcfTsProvider - currently listed in the XML file as RCFTSProvider
- RocfTsProvider - currently listed in the XML file as ROCFTSProvider
- CfdpRcvEntity - currently listed in the XML file as CFDPReceivingEntity (Note – this may be combined with the sending entity FR, but they are currently separate)
- RtnFileSvcProd - currently listed in the XML file as ReturnFileServer
- RtnFileDataStore - currently listed in the XML file as ReturnFileDataStore
- tdmSegmentGen - currently listed in the XML file as TDMSegmentGeneration
- TdmSink has been deleted from the reference model, although it is still present in the XML file as TDMSink
- TdmRcrdBuffer - currently listed in the XML file as TDMRecordingBuffer. Note – we have not yet formally agreed to abbreviate “recording” as “rcrd”, but I have done so in the Tech Note in order to reduce the size of its parameter’s classifier. But I am not adamant on this point and can change the Tech Note if necessary.
- TdCstsProvider - currently listed in the XML file as RealTimeTrackingDataCSTSProvider
- OpenLoopRxFormatter - currently listed in the XML file as OpenLoopReceiverFormatter
- OpenLoopDataStore
- DdorRawDataCollection - currently listed in the XML file as DDORRawDataCollection
- DdorRawDataStore - currently listed in the XML file as DDORRawDataStore
- NonValRmDataCollection - currently listed in the XML file as RawRadiometricDataCollection
- nonValRmDataStore - currently listed in the XML file as RawRadioMetricDataStore
- valRmDataStore - currently listed in the XML file as ValidatedRadiometricDataStore
- mdCstsProvider - currently listed in the XML file as MonitoredDataCSTSProvider
- mdCollection - currently listed in the XML file as MonitoredDataCollection
And as previously alluded to, we are eventually going to have to address the forward and return 415 space link carriers, and forward and return USLP (either by separate FRs or expansion of existing FRs – I am leaning toward new FRs).
Please review the list above and see if you concur with the classifiers as I have proposed them. Please don’t hesitate to ask why the proposed classifiers are as they are. If it would be useful, some of all of us could have a telecon to discuss some or all of these. The sooner that we can come to agreement on these classifiers the sooner I can post the FR errata sheets to the CWE.
Meanwhile, I will review (to the best of my ability) Wolfgang’s updates in the three FR Sets and update the errata sheets as appropriate.
Best regards,
John
From: Wolfgang Hell <wo_._he at t-online.de<mailto:wo_._he at t-online.de>>
Sent: Thursday, December 06, 2018 9:42 AM
To: Holger Dreihahn <Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>>; John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>; Pham, Timothy T (3300) <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>; Harald Ernst <harald.ernst at esa.int<mailto:harald.ernst at esa.int>>
Cc: Wolfgang Hell <whell at gmx.de<mailto:whell at gmx.de>>
Subject: FRs specified with the new tool
Dear All,
please find attached a file where I have updated the specifications of the FRs being elements of the following functional resource sets:
* RF Aperture Functional Resource Set (in the attached file incorrectly named "antenna")
* CCSDS 401 Forward Physical Channel Transmission Functional Resource Set
* CCSDS 401 Return Physical Channel Reception Functional Resource Set
I have produced those revised specifications using the latest version of the FR Editor that Holger has provided. Please disregard any FR specifications contained in that file that are not elements of the above listed FR Sets. But even the specification of the FRs being elements of those FR Sets are only a snapshot of "work in progress". My key objective was to gain hands-on experience with the new tool and to discover items that might still be open and require some further discussion. The attached update does not yet take into account all comments that you already had provided on earlier versions of the specification. I will do so in future versions and you do not need to send those comments again.
Having said that, my experience with the new tool is as follows:
Whatever I needed in order to specify the (in my mind) appropriate type of parameters is supported by the tool now. I'm really happy with our decision not to stick to the idea of precooked types any longer. When it comes to range constraints of parameters, the limits are now character strings, among others to enable the specification of such range of a REAL type. The previous version of the tool permitted numbers only and those were defaulted to 0 with the consequence that wherever I had used that default it is now undefined ('null'). If you come across such 'null', I simply missed in one or two cases to now explicitly specify the limit 0.
As you may recall, we always had a free text field for the specification of parameter types. This field is not affected by the new ASN.1 type specification. Holger and I had talked about it and agreed to leave those fields alone for now. However, when comparing the old and new type specifications, the difference is really major in some cases. This can be very confusing and therefore I replaced those type specifications in the above mentioned FRs with the now specified ASN.1 types. I had to do this manually for now, but perhaps Holger can update the tool such, that the ASN.1 is put automatically into that field.
There is one issue with those types. As you may recall, monitored values are qualified to show if they are valid or if not, why they are invalid. I have not included this "qualification" in the type specification because I felt that the type should be the same for reading and setting parameter values and because it is the same for all parameters so that this could be specified e.g. in the FR TN once and for all.
As we had discussed, there are some parameters for which we can be reasonably sure that setting of them by a cross support user will never be permitted, but likewise there are parameters for which we can be equally sure that setting by local EM must be possible. For now, I have (mis-)used the Guard Condition field to capture that information (the configure flag is not ticked in such case). I'm not sure if we should find a better place to capture that information or have three values for the configure flag: can be set by all, local only, not at all.
We also discussed that so far the FR specifications contain parameters that are useful or even mandatory for the local EM, but will never be used in the cross support context. However, we do not want to lose the information related to such "local" parameters. For the time being, we have no means to capture the information that a given parameter (or perhaps even specific values) are for local use only. Any suggestions in that respect are welcome.
Best regards,
Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20190227/7f70be4b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SANA FR Registry Issues.zip
Type: application/x-zip-compressed
Size: 754643 bytes
Desc: SANA FR Registry Issues.zip
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20190227/7f70be4b/attachment-0001.bin>
More information about the CSS-CSTS
mailing list