In Section 2.3.2 "File Operations", Table 2-1 is the description:

00b write from bus to slave's IFS
01b read to bus from slave's IFS

The terms "write from" and "read to" sound a little bit odd and
should be clarified

Table 2-1 is changed as follows (changed items are bold):

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.

Accept changes as proposed.

In order to be consistent with the remainder of the specification
on page 2-7 the term "node name" should be replaced by
"logical name".

Section 2.2.1 is changed as follows (changes are bold):

The conformance section of the Smart Transducers specification
(chapter 3 requirements and IDL) is not shaped right. It should be
expressed in terms of discrete mandatory or optional conformance
points. The name Conformance points is better suited that requirement
as this may be confused with the RFP requirements.

There are too many options to choose from in optional conformance
points, you should probably identify a few option sets that make sense
from a practical point of view.

Putting the Consolidated IDL in a separate chapter would also improve
clarity.

Also, it is customary to include a section (in the introduction)
describing how the submission adresses the mandatory and optional
points in the RFP.

In general take an other submission as an example of how conformance
statements are usually structured.

see above

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

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.

see above

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

Accept changes as proposed.

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."

Accept changes as proposed.

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.

Accept changes as proposed.

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."

Accept changes as proposed.

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."

see above

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."

see above

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

Accept changes as proposed.

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)."

Accept changes as proposed.

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."

Accept changes as proposed.

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."

Accept changes as proposed.

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.

Accept changes as proposed.

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".

Accept changes as proposed.

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.

Accept changes as proposed.

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".

Accept changes as proposed.

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.

see above

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.

see above

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

Accept changes as proposed.

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.“

Accept changes as proposed.

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.”

Accept changes as proposed.

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

Changed description.

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 > …”

Accept changes as proposed.

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.”

Accept changes as proposed.

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.“

Accept changes as proposed.

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.

Accept changes as proposed.

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

Accept changes as proposed.

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.

Accept changes as proposed.

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.

Accept changes as proposed.

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

management (DM) interface for better understanding.

Accept changes as proposed.