Issues for Smart Transducers Finalization task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5562: Support Text Change
Issue 5563: Support Text Change (02)
Issue 5564: Compliance point issues
Issue 5565: improve clarity the filenumber
Issue 5566: The diagnostic and maintenance (DM) interface should be renamed
Issue 5567: Range of system files should be extended
Issue 5568: Relax description of the configuration-file
Issue 5569: internal buffer in the IFS for MS-rounds
Issue 5570: Avoid ambiguity with the header-record 0x00 in section 2.7.1
Issue 5571: optional requirement should be added
Issue 5572: Section 3.4 (which is now Section 3.3) should be replaced
Issue 5573: Proposed IDL changes
Issue 5574: Section 3.8 should be adapted to reflect the changes in the IDL.
Issue 5596: change time format in order to make the offset obsolete
Issue 5597: A master is also an ST
Issue 5598: how to deal with unimplemented files
Issue 5599: reading the logical name is not mandatory
Issue 5600: remove parameter Time in Write()
Issue 5601: allow membership in slaves
Issue 5602: behaviour for multiple MSA or MSD rounds
Issue 5603: collapse TakeInstant and DeliveryInstant
Issue 5604: OP-Code for file operations
Issue 5605: description of broadcast
Issue 5606: transmission of in-band error codes
Issue 5607: add short description of membership vector
Issue 5608: add description of max. length of MP-round
Issue 5609: no need for an MP round between MS rounds
Issue 5610: the epoch-counter
Issue 5611: the owner file
Issue 5612: duplicate paragraph
Issue 5644: move checksums to application level

Issue 5562: Support Text Change (smart-transducers-ftf)

Multiple spaces or multiple line-feeds should be removed.

The replacement of "proposal" or "standard proposal" by "specification"

is suggested.

Some pictures should be centered.

Some typos should be removed.

In the former version the term "system file" denoted the configuration file

and the system file, but not the RODL file. Thus Section 2.4 "Smart Transducer 

Filesystem in the ST" should be restructured and some further explanations 

have to be added in order to make it easier understandable. 



The following paragraphs should be added:



"The namespace for files is subdivided into two parts:

* System Files (file nr. 0x00-0x0F and file nr. 0x38-0x3F)

* Application Specific Files (file nr. 0x10-0x37)"



and



"The System Files are dedicated to special tasks that are further described 

in the following sections (system files not covered in these sections are 

reserved for future extensions). All the remaining files are Application 

Specific Files and may be freely used in any desired manner as long as the 

first record (rec. nr. 0x00) contains the header record as specified above 

in order to be conformant to this specification."



This implicates that no further description is needed for the "Application

Specific Files" and the following chapters 2.4.x deal with "System Files"

only. These chapters should be reordered by ascending file-number of the 

respective files.

At the OMG Technical Meeting in Dublin the following things have been identified

by the AB as subject for revision:



1. Delete Sec. 3.3

2. List Sec. 3.1.1 and 3.2.1 as single mandatory compliance points.

3. Identify List of Functions in Secs. 3.1.2 and 3.2.2 as individual,

optional compliance points

In order to improve clarity the filenumber of the respective file should

be added to the headline of the Sections 2.4.x.

In Sec. 2.2.2 "index sequential file" should be replaced by "indexed sequential file".

Some pictures have been centered.

There are some typos in the document.

There are multiple spaces or multiple line-feeds in the document.

The diagnostic and maintenance (DM) interface should be renamed to diagnostic and 

management (DM) interface for better understanding.

In oder to have some system-files for spare, the range of system-files 

(0x08-0x0c, 0x3e-0x3f) should be extended to 0x08-0x0f, 0x38-0x3f.

The description of the configuration-file states that

"the configuration file (0x08) is mandatory for each ST node (master and slave)." 

Since this file is necessary only for plug and play or the sleep funtion this

should be relaxed to

"the configuration file (0x08) is necessary for each ST node (master and slave)

that supports plug and play or the sleep function."

It is of advantage to have an internal buffer in the IFS for MS-rounds. 

Since the files 0x01 and 0x05 are not used at all these files should be

reserved for this purpose.

In order to avoid ambiguity with the header-record 0x00 in section 2.7.1

"the first two records" should be replaced with "the second and third (0x01 and 

0x02) record".

For now it is unclear how an implementor may implement functions to

be conformant to this proposal. In order to allow an implementor to add application 

specific functions the following optional requirement should be added:

"An ST may support read-, write- or execute-operations on files with file nr. 0x10-0x37

in order to fulfill application specific purposes as long as record 0x00 is used as header

record as described in Section 2.4."

In order to prevent inconsistencies because of multiple occurrences of the range
of “Application Specific Files” the proposed text has been changed slightly.

Since embedded systems have limited resources only this standard should 

have no need for a naming service.

Section 3.4 (which is now Section 3.3) "Changes or Extensions required 

to adopted OMG Specifications" should be replaced by the following:

"A Smart Transducer object service may be used by an object to bootstrap itself into

operation; as such, this specification mandates an additional ObjectId for use in the

resolve_initial_references() operation defined in the ORB Initialization Specification,

OMG Document 94-10-24.

The following ObjectId is reserved for finding an initial Smart Transducer object

service:

SmartTransducer

No other extensions are proposed to OMG IDL, CORBA, and/or the OMG object

model."

There is no necessity of changing the specification “Enhanced View of Time”.
Thus the former content can be removed. Accept changes as proposed.

The IDL should be changed in the following way:



Exceptions should be removed because of their interrupt like nature. It

is better to check the error field at predefined instants. Thus the

struct AttributesData should be extended by the octet ERR.



The type AttributesData should be changed from unsigned long to a struct

with the subfields, that have been specified as bit-ranges before.



The type RecordData should be changed from unsigned long to octet[4] in

order to prevent problems with endianess.

In addition to the proposed changes the IDL has been extended by a comment
containing the name of the file.

Section 3.8 should be adapted to reflect the changes in the IDL. (issue5573)

Even the smallest 8-bit microcontrollers should be capable of dealing with signed numbers in the 2-complement representation. Thus the following changes are proposed:
In Section 2.3.8 "... plus an offset of 2^38 seconds. The offset is introduced to be able to express instants before January 6, 1980 as positive values." should be replaced by "Instants before January 6, 1980 are represented as negative values."
The IDL in Section 3.4 should be changed in the following way:
"typedef unsigned long long TimeInstant" should be replaced by "typedef long long TimeInstant" and "typedef unsigned long long TimeDuration" should be changed to "typedef unsigned long long TimeDuration"; in addition the description in Section 3.5 must be changed

A master is also an ST. Thus in the first paragraph of Section 2.2.1 
"The master of each cluster is connected to the CORBA gateway through a real-time communication network, which provides a synchronized time to each master. [...] Since the STs are controlled by the master, we call them also slave nodes."
should be replaced by
"The master (an ST with extended features) of each cluster is connected to the CORBA gateway through a real-time communication network, which provides a synchronized time to each master. [...] Since the other STs are controlled by the master, we call them slave nodes also."

For now it is unclear how to deal with records in system-files with functions that are not implemented. Thus in Section 2.4 the following should be added:
"If a file is not implemented there is no need to implement the respective header record; the "NoFile"-error is returned instead. Unimplemented records in the middle of a file should return 0x00 in order to prevent holes in the IFS (the "NoRecord"-error is applicable for records beyond the length of a file only)."

Since it is not mandatory for proper function to read the logical name in Section 3.1 "in order to allow reading the physical name and the logical name of an ST" should be replaced by " in order to allow reading the physical name of an ST".

Since changing the TakeInstants and the DeliveryInstants in an ST cluster is a fundamental change of the clusters behavior, these changes are only possible by changing the RODL and/or ROSE files by using the CP-interface. Thus setting the delivery time in the RS-interface for the function Write() should be prevented by using the RS-interface. and the parameter in TimeInstant Time should be removed.
Then it is only necessary to translate timestamps from the cluster internal time to the external time. Translating the time-format in the other way is an optional requirement then.
Thus in Section 3.1 "Every master must provide the capability to translate the representation of the external time to the representation of the internal time of its cluster and vice versa." should be relaxed to "Every master must provide the capability to translate the representation of the internal time of its cluster to the representation of the external time."
In addition the following optional requirement should be added to Section 3.2:
"Convert external time to cluster-internal time: This function enables an ST to convert the external time into the cluster internal format." Thus in Section 3.1 "Every master must provide the capability to translate
the representation of the external time to the representation of the internal
time of its cluster and vice versa." should be relaxed to "Every master must
provide the capability to translate the representation of the internal time of
its cluster to the representation of the external time."
In addition the following optional requirement should be added to Section 3.2:
"Convert external time to cluster-internal time: This function enables an ST
to convert the external time into the cluster internal format."

There is no reason that the membership vector is available in the master only. Thus Section 3.2 "Optional Requirements" and 2.4.3 "The Membership File" should be changed accordingly.

In Section 2.3.3 it is unclear, how an ST should behave when multiple MSA or
MSD rounds have been received (e.g. because an MSA round was not received
correctly).
Thus the following paragraph should be added in Section 2.3.3:
"If multiple MSA rounds are received it should be assumed that some MSD
rounds got lost and thus the last MSA round is chosen. If multiple MSD
rounds are received it should be assumed that the intermediate MSA
rounds got lost and thus only the first MSD round is valid while the
remaining MSD rounds are dropped. Thus the system provides additional
resistance against unintended operations because of missed MSA or MSD
rounds."

The IDL in Section 3.4 contains struct TakeInstant and struct DeliveryInstant containing the same subfields. These types should be replaced by a single struct Instants (the plural because it is not just one single instant).
Thus the functions ReadDeliveryInstant() and ReadTakeInstant() should also be renamed to ReadDeliveryInstants() and ReadTakeInstants().
The description in Section 3.5 has to be changed too

It is unclear if the OP-Code uses the upper or the lower 2 bits in Section 2.3.2
“File Operations”. Since using the lower 2 Bits make calculations of addresses
more easy the following changes are proposed:
“Together with the 64 file names (6 bits) (which an ST can hold), the file
operation and the file name can be fitted into a single byte.“
should be changed to
“Since an ST can hold up to 64 files, the file name (6 upper bits) and the file
operation (2 lower bits) can be fitted into a single byte.“
In addition the description of the MS-Round in Section 2.3.3 should be changed
to “… <file name | operation > …”

In the description of the broadcast round in Section 2.3.2 it seems, that a broadcast round is different to a MS-round. In fact it is a MS-round with logical Name 0x00

It is unclear how the in-band error codes are transmitted in an MS round. This
should be clarified by adding the following paragraph to Section 2.3.3:
“The check byte is also used for transmitting inline error codes. In case of
an error, all four data bytes of the MSD-Round are set to 0xFF and the
check byte contains an error code in the lower nibble while the bits of the
higher nibble are all set. Note that a message containing the value
0xFFFFFFFF differs significantly from an error message in the check byte.”

For better understanding a short description of the mechanism behind the
membership vector should be added to Section 2.3.3:
„Two optional membership vectors (bit fields) are defined (see Section
2.4.3). Every time the master receives from an ST a correct response within
an MS round it sets the corresponding bit of the second membership
vector. If none or a wrong answer is received, the respective bit is cleared.“

For better understanding a short description of the max. length of an MP round
should be added to Section 2.3.4:
„Since Slot 0 is reserved for the firework and the last slot of a round is
reserved for the Inter Round Gap (IRG), an MP round may be used to
communicate up to 62 data bytes because a valid MP round is limited to 64
slots in total.“

It is mandatory that at the end of each round is an Inter-Round-Gap (IRG) of at
least one slot. This gap leaves a slave enough time to process an MSA round.
Thus there is no need for setting constraints to the order of the rounds. In Section
2.3.6 the following sentence should be removed then:
“Between any two MP rounds there must be an interval of sufficient
duration to execute one phase of an MS round, as depicted in Figure 2-5.”

The former usage of the epoch counter (one epoch lasts from one MSA round to the next) sets some constraints about the max. number of slots available for MP rounds. It is easier implementable and more convenient if the epoch counter implicitely is incremented witch each fireworks byte. As an additional advantage the pair (epoch counter, slot counter) can be used as timestamp in the ST cluster. Thus these values should be made available in the IFS for application tasks.
Resolution:
The meaning of the epoch is changed. In addition to the values "epoch counter" and "slot counter" the "currently assigned cluster name", the "number of the current round", and the current state of the nodes protocol is made available in the "Configuration File (file no. 0x08)". Supporting the epoch counter is an optional service for an ST.
Since the maximum length of an MP round has been based on the horizon of the slot-counter this also influences the maximum length of a MP round. Another constraint is the length of the owner file (see issue XXXX). Thus the length of an MP round is limited to 64 Slots.

The meaning of the epoch is changed. In addition to the values “epoch counter”
and “slot counter” the “currently assigned cluster name”, the “number of the
current round”, and the current state of the nodes protocol is made available in
the “Configuration File (file no. 0x08)”. Supporting the epoch counter is an
optional service for an ST.
Since the maximum length of an MP round has been based on the horizon of the
slot-counter this also influences the maximum length of a MP round. Another
constraint is the length of the owner file (see issue 5611). Thus the length of an
MP round is limited to 64 Slots.

Updating the first membership vector requires that the ST knows which ST should send in a specific slot. This information is not available for now.
Resolution:
This problem requires an additional file containing this information. This file is called "Owner File" and uses file no. 0x0B.

This problem requires an additional file containing this information. This file is
called “Owner File” and uses file no. 0x0B.

In Section 2.6.1 "Representation of Observed Transducer Data" one paragraph occurs twice. Thus one paragraph should be removed

It is proposed that the protocol provides checksums for parts of the MP rounds.
Then the application has to check a flag if the checksum has been correct and
react accordingly. Since the calculation of the checksum (some exclusive or
operations) is not significantly more effort than checking the flag the checksum
calculation should be moved to the application layer.