Smart Transducers Avatar
  1. OMG Specification

Smart Transducers — All Issues

  • Acronym: SMART
  • Issues Count: 34
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SMART11-3 Clarify description of OP-Codes SMART 1.0 SMART 1.1 Resolved closed
SMART-31 move checksums to application level SMART 1.0b1 SMART 1.0 Resolved closed
SMART11-2 replace "node name" with "logical name" SMART 1.0 SMART 1.1 Resolved closed
SMART11-1 Conformance section SMART 1.0 SMART 1.1 Resolved closed
SMART-13 Section 3.8 should be adapted to reflect the changes in the IDL. SMART 1.0b1 SMART 1.0 Resolved closed
SMART-12 Proposed IDL changes SMART 1.0b1 SMART 1.0 Resolved closed
SMART-21 collapse TakeInstant and DeliveryInstant SMART 1.0b1 SMART 1.0 Resolved closed
SMART-20 behaviour for multiple MSA or MSD rounds SMART 1.0b1 SMART 1.0 Resolved closed
SMART-19 allow membership in slaves SMART 1.0b1 SMART 1.0 Resolved closed
SMART-18 remove parameter Time in Write() SMART 1.0b1 SMART 1.0 Resolved closed
SMART-11 Section 3.4 (which is now Section 3.3) should be replaced SMART 1.0b1 SMART 1.0 Resolved closed
SMART-10 optional requirement should be added SMART 1.0b1 SMART 1.0 Resolved closed
SMART-14 change time format in order to make the offset obsolete SMART 1.0b1 SMART 1.0 Resolved closed
SMART-16 how to deal with unimplemented files SMART 1.0b1 SMART 1.0 Resolved closed
SMART-15 A master is also an ST SMART 1.0b1 SMART 1.0 Resolved closed
SMART-7 Relax description of the configuration-file SMART 1.0b1 SMART 1.0 Resolved closed
SMART-6 Range of system files should be extended SMART 1.0b1 SMART 1.0 Resolved closed
SMART-9 Avoid ambiguity with the header-record 0x00 in section 2.7.1 SMART 1.0b1 SMART 1.0 Resolved closed
SMART-8 internal buffer in the IFS for MS-rounds SMART 1.0b1 SMART 1.0 Resolved closed
SMART-17 reading the logical name is not mandatory SMART 1.0b1 SMART 1.0 Resolved closed
SMART-29 the owner file SMART 1.0b1 SMART 1.0 Resolved closed
SMART-28 the epoch-counter SMART 1.0b1 SMART 1.0 Resolved closed
SMART-30 duplicate paragraph SMART 1.0b1 SMART 1.0 Resolved closed
SMART-25 add short description of membership vector SMART 1.0b1 SMART 1.0 Resolved closed
SMART-24 transmission of in-band error codes SMART 1.0b1 SMART 1.0 Resolved closed
SMART-23 description of broadcast SMART 1.0b1 SMART 1.0 Resolved closed
SMART-22 OP-Code for file operations SMART 1.0b1 SMART 1.0 Resolved closed
SMART-27 no need for an MP round between MS rounds SMART 1.0b1 SMART 1.0 Resolved closed
SMART-26 add description of max. length of MP-round SMART 1.0b1 SMART 1.0 Resolved closed
SMART-4 improve clarity the filenumber SMART 1.0b1 SMART 1.0 Resolved closed
SMART-3 Compliance point issues SMART 1.0b1 SMART 1.0 Resolved closed
SMART-2 Support Text Change (02) SMART 1.0b1 SMART 1.0 Resolved closed
SMART-1 Support Text Change SMART 1.0b1 SMART 1.0 Resolved closed
SMART-5 The diagnostic and maintenance (DM) interface should be renamed SMART 1.0b1 SMART 1.0 Resolved closed

Issues Descriptions

Clarify description of OP-Codes

  • Key: SMART11-3
  • Legacy Issue Number: 5746
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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

  • Reported: SMART 1.0 — Mon, 4 Nov 2002 05:00 GMT
  • Disposition: Resolved — SMART 1.1
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 09:10 GMT

move checksums to application level

  • Key: SMART-31
  • Legacy Issue Number: 5644
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Fri, 6 Sep 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 21:40 GMT

replace "node name" with "logical name"

  • Key: SMART11-2
  • Legacy Issue Number: 6013
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0 — Thu, 24 Jul 2003 04:00 GMT
  • Disposition: Resolved — SMART 1.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conformance section

  • Key: SMART11-1
  • Legacy Issue Number: 5686
  • Status: closed  
  • Source: Alcatel-Lucent ( Julien Maisonneuve)
  • Summary:

    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.

  • Reported: SMART 1.0 — Mon, 14 Oct 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: SMART-13
  • Legacy Issue Number: 5574
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Proposed IDL changes

  • Key: SMART-12
  • Legacy Issue Number: 5573
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

collapse TakeInstant and DeliveryInstant

  • Key: SMART-21
  • Legacy Issue Number: 5603
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

behaviour for multiple MSA or MSD rounds

  • Key: SMART-20
  • Legacy Issue Number: 5602
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allow membership in slaves

  • Key: SMART-19
  • Legacy Issue Number: 5601
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

remove parameter Time in Write()

  • Key: SMART-18
  • Legacy Issue Number: 5600
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.4 (which is now Section 3.3) should be replaced

  • Key: SMART-11
  • Legacy Issue Number: 5572
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

optional requirement should be added

  • Key: SMART-10
  • Legacy Issue Number: 5571
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

change time format in order to make the offset obsolete

  • Key: SMART-14
  • Legacy Issue Number: 5596
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

how to deal with unimplemented files

  • Key: SMART-16
  • Legacy Issue Number: 5598
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A master is also an ST

  • Key: SMART-15
  • Legacy Issue Number: 5597
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relax description of the configuration-file

  • Key: SMART-7
  • Legacy Issue Number: 5568
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Range of system files should be extended

  • Key: SMART-6
  • Legacy Issue Number: 5567
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Avoid ambiguity with the header-record 0x00 in section 2.7.1

  • Key: SMART-9
  • Legacy Issue Number: 5570
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

internal buffer in the IFS for MS-rounds

  • Key: SMART-8
  • Legacy Issue Number: 5569
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reading the logical name is not mandatory

  • Key: SMART-17
  • Legacy Issue Number: 5599
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the owner file

  • Key: SMART-29
  • Legacy Issue Number: 5611
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the epoch-counter

  • Key: SMART-28
  • Legacy Issue Number: 5610
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

duplicate paragraph

  • Key: SMART-30
  • Legacy Issue Number: 5612
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add short description of membership vector

  • Key: SMART-25
  • Legacy Issue Number: 5607
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

transmission of in-band error codes

  • Key: SMART-24
  • Legacy Issue Number: 5606
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of broadcast

  • Key: SMART-23
  • Legacy Issue Number: 5605
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Changed description.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OP-Code for file operations

  • Key: SMART-22
  • Legacy Issue Number: 5604
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no need for an MP round between MS rounds

  • Key: SMART-27
  • Legacy Issue Number: 5609
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add description of max. length of MP-round

  • Key: SMART-26
  • Legacy Issue Number: 5608
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

  • Reported: SMART 1.0b1 — Tue, 27 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

improve clarity the filenumber

  • Key: SMART-4
  • Legacy Issue Number: 5565
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance point issues

  • Key: SMART-3
  • Legacy Issue Number: 5564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support Text Change (02)

  • Key: SMART-2
  • Legacy Issue Number: 5563
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support Text Change

  • Key: SMART-1
  • Legacy Issue Number: 5562
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

    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.

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The diagnostic and maintenance (DM) interface should be renamed

  • Key: SMART-5
  • Legacy Issue Number: 5566
  • Status: closed  
  • Source: Institut fuer Technische Informatik ( Thomas Losert)
  • Summary:

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

    management (DM) interface for better understanding.

  • Reported: SMART 1.0b1 — Mon, 5 Aug 2002 04:00 GMT
  • Disposition: Resolved — SMART 1.0
  • Disposition Summary:

    Accept changes as proposed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT