Issues for Mailing list of the Ground Equipment Monitoring Service 1.0 (GEMS) Finalization Task Force

To comment on any of these issues, send email to gems-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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

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

Issue 12753: Correct various table and section references throughout the document
Issue 12754: Section 7.3.2
Issue 12756: GEMS PIM Section 7.3.1.7: 64 Bit Integer Values
Issue 12757: GEMS PIM 7.3.2.1.5 Time stamp definition is vague and needs to be clarified
Issue 12758: GEMS PIM 7.3.2.4.2.1 The valid_state field is confusing
Issue 12759: GEMS PIM 7.7 Standard Device definitions not complete
Issue 12760: GEMS PIM 7.5 Spelling error in section 7.5
Issue 12761: GEMS-XML 8.1.1.9 XML Schema for Connect Request includes client_version
Issue 12762: 8.1.1.17 The XML schema for GetConfigResponse uses an undefined ConfigResul
Issue 12763: GEMS-XML 8.2.1 Need two additional examples in Directive Message/Response
Issue 12764: GEMS-XML 8.2.5 Typo in section 8.2.5: example indicates 2 params
Issue 12765: GEMS-ASCII messages do not specify a starting or trailing pipe character
Issue 12766: Response message examples do not clearly show the result_description.
Issue 12767: 9.1.1.1 Need to clarify how hex_value types are specified in the ASCII PSM
Issue 12768: GEMS-ASCII PSM is missing the ParameterSet definition
Issue 12769: No discussion of escaping or quoting characters in the ASCII PSM
Issue 12770: 9.1.2 Figure in 9.1.2 uses RTL instead of GEMS
Issue 12771: 9.2.2 Section 9.2.2: The example shows an incorrect message type
Issue 12772: Sections 9.2.6 & 9.2.7
Issue 12966: Need an example of how to represent a parameter array in the GEMS-XML PSM
Issue 12967: Add XML and ASCII as normative references
Issue 12968: VALID_RANGE description contains extra copy of message UML image
Issue 13133: header of the GEMS_base_types.xsd file does not match with section 7.1.1 of the GEMS Specification Beta 1

Issue 12753: Correct various table and section references throughout the document (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are a number of places where internal table references are incorrect. This includes a few places where XXX is used.

Resolution: All table references have been updated to reference existing tables with correct table numbers.
Revised Text: In the first row (not counting the header row) of tables 8.3, 8.5, 8.6, 8.7, 8.8, 8.9, 8.10, 8.11 and the tables in sections 8.1.8.1, 8.1.8.2, 8.1.9.1, 8.1.9.2 Change '<See Table 2> to <See Table 8.2>. In the last row of tables 8.6, 8.7, 8.8, 8.9, 8.10 and the tables in sections 8.1.8.1, 8.1.8.2. 8.1.9.1 and 8.1.9.2 Change <See Table 4> to <See Table 8.4> In row 5 of tables 8.8 and 8.9 describing field "Parameter Value 1' and row 8 of tables 8.8 and 8.9 describing field "Parameter Value n" Change <See Table 1> to <See Table 8.1> In row 7 of table 8.11 describing field "Parameter 1' and row 10 describing field "Parameter n" Change <See Table 2> to <See Table 8.1> In row 7 of table in section 8.1.11.2 describing field "Return Value 1' and row 10 describing field "Return Value n" Change <See Table 2> to <See Table 8.1> In row 5 of table 8.10 describing field "Valid State" Change "Whether or not the set succeeded. <See section XXX>" To "Whether or not the set succeeded." In section 8.1.5.2 Change "See Sections 8.1.1 and 8.1.2 To "See Sections 8.1.3 and 8.1.4" Disposition: Resolved
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12754: Section 7.3.2 (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

Need a message to retrieve the list of saved/available configuration files. There is no current way to obtain the list of available configurations.

Resolution: In the PIM the new messages are called GetConfigListMessage and GetConfigListResponse. The GetConfigListResponse includes a list of strings. Each string provides the name of a configuration.
Revised Text: Figure 6.3 replaced with new UML as follows Added new section 6.3.3.7 as follows 6.3.3.7 Retrieving Available Configurations In order to restore a named configuration to a GEMS device, the GEMS user needs to be provided a mechanism for retrieving all the configurations available. This message identifies the list of configuration names available to load. The following diagram depicts the UML structure for these messages. Figure 6.12 - Get Configuration List UML GetConfigListMessage The GetConfigListMessage does not contain any additional information above and beyond the base message class. GetConfigListResponse configuration_name The configuration_name field contains all of the available configuration names for the GEMS device. The format of the names is dictated by the device developer. Added new section 8.1.10 'GetConfigListMessage' and Response with subsections 8.1.10.1 'GetConfigListMessage' and 8.1.10.2 'GetConfigListMessage Response' as follows. 8.1.10 GetConfigListMessage and Response The following tables describe the message body and response for the GetConfigListMessage. 8.1.10.1GetConfigListMessage Table 8. 11 - GetConfigList Request Message Field Names Length (char) Range of Values Comments Standard Header Variable <See Table 8.2> Message Type Field = SAVE or LOAD Field Delimiter 1 | Pipe character (ASCII 124) Standard Trailer 3 <See Table 8.4> 8.1.10.2 GetConfigListMessage Response Table 8. 11 - GetConfigListMessage Response Field Names Length (char) Range of Values Comments Standard Header Variable <See Table 8.2> Message Type Field = DIR-R Field Delimiter 1 | Pipe character (ASCII 124) Number of Configuration Names Variable Numeric ( >= 0 ) Number of configuration names avaialable Configuration Name 1 Variable Alphanumeric Name of 1st configuration available Field Delimiter 1 | Pipe character (ASCII 124) … Configuration Name n Variable Alphanumeric Name of nth configuration available Field Delimiter 1 | Pipe character (ASCII 124) Added new section 7.1.1.8 to the GEMS-XML PSM to define the GetConfigListMessage as follows 7.1.1.8 GetConfigListMessage The XML mapping for a GEMS GetConfigListMessage is as follows: <xsd:complexType name="GetConfigListMessageType"> <xsd:complexContent> <xsd:extension base="MessageType"> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="GetConfigListMessage" type="GetConfigListMessageType"/> Added new section 7.1.1.17 to the GEMS-XML PSM to define the GetConfigList response message as follows 7.1.1.17 Get Config List Response The GEMS-XML mapping for the GetConfigListResponse message is as follows: <xsd:complexType name="GetConfigListResponseType"> <xsd:complexContent> <xsd:extension base="ResponseMessageType"> <xsd:sequence> <xsd:element minOccurs="0" maxOccurs="unbounded" name="ConfigurationName" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="GetConfigListResponse" type="GetConfigListResponseType"/> Added new section 7.2.3 'GetConfigList Message / Response' and subsections 7.2.3.1 'GetConfigListMessage Example' and 7.2.3.2 'GetConfigList Response Example as follows 7.2.3 GetConfigList Message / Response The following is an example of a GetConfigListMessage 7.2.3.1 GetConfigListMessage Example <GetConfigListMessage xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="1234" token="CS12345" target="FrameSync1" gems_version="1"/> 7.2.3.2 GetConfigList Response Example <GetConfigListResponse xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="1234" token="CS12345" target="FrameSync1" gems_version="1"> <Result>SUCCESS</Result> <ConfigurationName>default.xml</ConfigurationName> <ConfigurationName>SpaceVehicle1.xml</ConfigurationName> <ConfigurationName>SpaceVehicle2.xml</ConfigurationName> </GetConfigListResponse> Disposition: Resolved
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12756: GEMS PIM Section 7.3.1.7: 64 Bit Integer Values (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

Should 64 bit integer values be added to the PIM?

Resolution: Define the long type to be 64 bits in length. Originally the long type was redundant with the integer type. This approach matches the types used in XML.
Revised Text: In section 6.3.1.5 Change "Represents a signed 4 byte value." To "Represents a signed 8 byte value." In section 6.3.1.6 Change "Represents an unsigned 4 byte value." To "Represents an usigned 8 byte value."
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12757: GEMS PIM 7.3.2.1.5 Time stamp definition is vague and needs to be clarified (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The time stamp in the message header is loosely defined in the document. Need to clarify this. Suggest UTC following the time parameter type.

Resolution: Update all related time stamp fields to specify UTC. Also changed the examples in the GEMS-ASCII PSM section to us ASCII time parameter format for the time stamp. NOTE: There is an associated issue with this that was identified during the voting process. The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution. Because the format of the message will likely not change, this should not impact GEMS 1.0 implementations. There are however several considerations that need to be taken in to account before a final decision can be made on using UTC vs POSIX. Therefore, the FTF is accepting the 3/4 yes vote as resolution of issue 12757. A new issue has been created (13132) and will be handled under a subsequent RTF to specifically address the UTC vs POSIX time concerns.
Revised Text: In section 6.3.2.1 'timestamp' update text of paragraph Before The timestamp field provides useful debugging and message sorting information. The value in the field is the current time when the message is sent. The format of the field is defined in the PSM. After The timestamp field provides useful debugging and message sorting information. The value in the field is the current time when the message is sent in UTC. The format of the field is defined in the PSM. In Section 7.1.1.4 'Message' update text of paragraph Before The GEMS-XML mapping for the GEMS message class is shown in the XML schema below. The Message element contains attributes for the version, token, target, transaction_id, and timestamp. After The GEMS-XML mapping for the GEMS message class is shown in the XML schema below. The Message element contains attributes for the version, token, target, transaction_id, and timestamp specified in UTC. The timestamp string format follows the format specified for the time type in the ASCII PSM which is "seconds.nanoseconds". See Table 8.1. In Table 8.2 modified timestamp row values as follows: Length was 24 is now 19 Range was :ddd:hh:mm:ss:msmsms:ususus is now 111111111.222222222 Comments was "Timestamp of when the message was sent" is now "Timestamp of when the message was sent in UTC. Uses the format of the time parameter specified in:" In section 8.2 the following lines representing ASCII PSM message examples: 1550, 1553, 1556, 1560, 1562, 1566, 1569, 1572, 1574, 1577, 1579, 1582 and 1585 had their timestamp tokens modified as follows Before T05:011:16:30:00:000:000 After 111111111.222000000
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12758: GEMS PIM 7.3.2.4.2.1 The valid_state field is confusing (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The invalid_state field in the SetConfigResponse and LoadConfigResponse is confusing and might not apply to all cases (e.g. software only implementation). The original idea behind this was to provide a way to
indicate whether or not the hardware was left in a valid state in the event of an error.
Suggest moving this to a HARDWARE_ERROR ResultCode

Resolution: Remove the valid_state Boolean members of the SetConfigResponse and LoadConfigResponse classes in the PIM. This change also needs propagating throughout the document. All references and sections to valid_state must be removed.
Revised Text: Revised Text: In section 6.3 figure 6.3 has been replaced with an updated figure that removes the valid_state Boolean member of the SetConfigResponse and LoadConfigResponse classes. In section 6.3.3.1 remove the last line of paragraph. In section 6.3.3.1 remove the sub-section titled valid_state. In section 6.3.3.6 remove the sub-section titled valid_state. In sections 7.1.1.15 and 7.1.1.18 remove the following line of the provided XML schema section: <xsd:element maxOccurs="1" minOccurs="0" name="valid_state" type="xsd:Boolean"/> In section 7.2.4.2 remove the following line of the provided XML example: <valid_state>true<valid_state/>
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12759: GEMS PIM 7.7 Standard Device definitions not complete (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The standard device definitions are not defined yet. The original thought was that this section is populated by later revisions.
Suggest this be left for future versions/FTF.

Resolution: Suggest this section be left empty with a short description regarding the notion of consistency across common devices. Future versions/FTF will expand this section with specific examples.
Revised Text: In section 6.7 paragraph 1 Before This section contains standard device definitions. The intent of these definitions is to offer a degree of interoperability across device vendors. This allows GEMS users to swap GEMS devices of like types with minimal impact to application software. The notion of a dictionary is used rather than a strict taxonomy to more easily accommodate the wide variation of ground system equipment. Vendors are encouraged to use the standard parameter definitions. After In future revisions this section will contain industry standard device definitions. The intent of these definitions is to offer a degree of interoperability across device vendors. This allows GEMS users to swap GEMS devices of like types with minimal impact to application software. Remove the entire section 6.7.1 including subsections.
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12760: GEMS PIM 7.5 Spelling error in section 7.5 (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorrect: ''Users connecting to a GEMS device are provide a token...''
Should be: ''.. are provided a token''

Resolution: Simple correct the spelling error.
Revised Text: In section 6.5 paragraph one change "provide" in the first line to "provided".
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12761: GEMS-XML 8.1.1.9 XML Schema for Connect Request includes client_version (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The client_version is not defined in the PIM but offers the potential for client/server negotiations. This though might be too complex of a notion. Need to either delete it from the schema or update the PIM.
Recommend deleting it.

Resolution: It is recommended that this notion of client_version be left out of the first version and reviewed for possible consideration at a later date.
Revised Text: In section 7.1.1.9 the schema definition has been modified Before <xsd:complexType name="ConnectionRequestMessageType"> <xsd:complexContent> <xsd:extension base="MessageType"> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="client_version" type="xsd:string"/> <xsd:element maxOccurs="1" minOccurs="1" name="type" type="ConnectionType"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> After <xsd:complexType name="ConnectionRequestMessageType"> <xsd:complexContent> <xsd:extension base="MessageType"> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="type" type="ConnectionType"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType>
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12762: 8.1.1.17 The XML schema for GetConfigResponse uses an undefined ConfigResul (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no type defined for ConfigResult in either the PSM or the PIM. This is meant to be the result_description

Resolution: The 'ConfigResult' type is really meant to be the 'result_description' defined in the base 'ResponseMessageType' in section 7.1.1.19.
Revised Text: In section 7.1.1.19 the schema definition has been modified. Before  <xsd:complexType name="GetConfigResponseType"> <xsd:complexContent> <xsd:restriction base="MessageType"> <xsd:sequence> <xsd:element name="Parameter" type="Parameter" minOccurs="0" maxOccurs="unbounded"/>  <xsd:element name="ParameterSet" type="ParameterSet" minOccurs="0" maxOccurs="unbounded"/>  <xsd:element name="result" type="ConfigResult"/> </xsd:sequence> </xsd:restriction> </xsd:complexContent> </xsd:complexType>  <xsd:element name="GetConfigResponse" type="GetConfigResponseType"/> After  <xsd:complexType name="GetConfigResponseType"> <xsd:extension base="ResponseMessageType"> <xsd:sequence> <xsd:element name="Parameter" type="Parameter" minOccurs="0" maxOccurs="unbounded"/>  <xsd:element name="ParameterSet" type="ParameterSet" minOccurs="0" maxOccurs="unbounded"/>  <xsd:element name="result" type="ConfigResult"/> </xsd:sequence> </xsd:extension> </xsd:complexType>  <xsd:element name="GetConfigResponse" type="GetConfigResponseType"/>
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12763: GEMS-XML 8.2.1 Need two additional examples in Directive Message/Response (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The examples would be enhanced by providing an example of a directive with parameters and one with return values. Maybe these can be combined.

Resolution: It seems appropriate to modify the example of a directive message in section 7.2.1 to include at least one parameter in the directive message and one return value in the directive message response. This would provide one comprehensive example of a directive message in the XML PIM.
Revised Text: In section 7.2.1 change paragraph 1 Before The following is an example of a directive message that activates a frame synchronizer. This particular directive does not require any arguments. After The following is an example of a directive message that activates a frame synchronizer. This particular directive does require one argument and returns one value. In section 7.2.1.1 replace directive message example Before <DirectiveMessage xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="1234" token="CS12345" target="FrameSync1" gems_version="1"> <directive_name>run</directive_name> </DirectiveMessage> After <DirectiveMessage xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="1234" token="CS12345" target="FrameSync1" gems_version="1"> <directive_name>run</directive_name> <Parameter name="enable"> <boolean>true</boolean> </Parameter> </DirectiveMessage> In section 7.2.1.2 replace directive message response example Before <DirectiveResponse xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="1234" token="CS12345" target="FrameSync1" gems_version="1"> <Result>SUCCESS</Result> <directive_name>run</directive_name> </DirectiveResponse> After <DirectiveResponse xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="1234" token="CS12345" target="FrameSync1" gems_version="1"> <Result>SUCCESS</Result> <directive_name>run</directive_name> <Parameter name="enabled"> <boolean>true</boolean> </Parameter> </DirectiveResponse>
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12764: GEMS-XML 8.2.5 Typo in section 8.2.5: example indicates 2 params (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The example only shows one parameter. Need to update one or the other.

Resolution: The example is sufficient so it was decided to update the description to indicate only parameter would be requested.
Revised Text: In section 7.2.5 update paragraph 1 Before The following is a example of a GetConfigMessage requesting two parameters. After The following is a example of a GetConfigMessage requesting one parameter.
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12765: GEMS-ASCII messages do not specify a starting or trailing pipe character (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

GEMS-ASCII messages do not specify a starting or trailing pipe character in either the table or in the examples. Dave's recommendation is to put this at the beginning of each message.

Resolution: A beginning pipe will be added to the definition of the ASCII PSM message header. No ending pipe will be specified as one or the other is sufficient for parsing purposes.
Revised Text: In table 8.2 inserted the following row as the first row of the table: Field Names = 'Field Delimiter' Length = '1' Range of Values = '|' Comments = 'Pipe character (ASCII 124)' Added '|' (pipe character) to the beginning of each example ASCII message and response in the following sections: 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.6
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Discussion:

Issue 12766: Response message examples do not clearly show the result_description. (gems-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Dave noted that the examples in the document do not clearly show the result description text. A simple ''Desc'' can be hidden. Better examples will help clear this up

Resolution: Replace all 'Desc' text with wordier descriptions that are obviously visible.
Revised Text: In section 8.2.1 Connect Message Example line 1551 Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|CON-R|SUCCESS|A description|END After GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|CON-R|SUCCESS|The GET request was successful.|END In section 8.2.4 SetConfigMessage Example line 1567 Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|SET-R|SUCCESS|Desc|2|TRUE|END After GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|SET-R|SUCCESS|The SET request was successful.|2|TRUE|END In section 8.2.5 SaveConfigMessage Example line 1572 Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|SAVE-R|SUCCESS|Desc|100|0|END After GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|SAVE-R|SUCCESS|The SAVE request was successful.|100|0|END In section 8.2.6 LoadConfigMessage Example line 1577 Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|LOAD-R|SUCCESS|Desc|100|0|END After GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|LOAD-R|SUCCESS|The LOAD request was successful.|100|0|END In section 8.2.7 DirectiveMessage Example line 1583 Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|DIR-R|SUCCESS|Desc|sendVehicleCommand|1|0|accepted:bool=true|END After GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|DIR-R|SUCCESS|The DIR request was successful.|sendVehicleCommand|1|0|accepted:bool=true|END
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Discussion:

Issue 12767: 9.1.1.1 Need to clarify how hex_value types are specified in the ASCII PSM (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are two questions regarding hex_value types in the GEMS-ASCII PSM.
# Hex value arrays are not well defined and the concept is complicated.
# Can we use a 0xFFFF notation?
Suggestions:
Yes, the 0xFFFF notation can be used but it should be optional. ''(e.g. FAFA is the same as 0xFAFA)''
As for arrays, this is a little complicated. Suggestions are as follows:
* Restrict arrays of hex_values to be the same bit length
* Move the bit length to the parameter value: e.g. hex_value[2]=22.FAF320,15.EB90 would specify an array with a 22 bit field and a 15 bit field
RT Logic's recommendation is to use the 2nd option.

Resolution: The GEMS PIM hex_value definition will be updated to make clear that all hex_values contained in arrays of hex_values must be of the same bit length. The ASCII PSM definition will be updated to make clear what formats are allowable for hex_values.
Revised Text: Section 6.3.1.13 has been modified to include the following line at the end of the paragraph: In cases where the multiplicity is greater than one the bit_length attribute of the hex_values must all be equal. Section 8.1.1.1 in table 8.1 the example format for hex_value has been updated. Before param:hex_value(22)=faf320 After param:hex_value(22)=faf320 param:hex_value(22)=0xfaf320
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12768: GEMS-ASCII PSM is missing the ParameterSet definition (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no description of ParameterSets in the GEMS-ASCII PSM. This needs to be added.

Resolution: Discuss and flush out appropriately.
Revised Text: In section 8.1.1.2 replace section: Before In the PSM ASCII Mapping parameter sets may be defined by the additional use of colons. For example an array of integers would be represented as follows: param_int_array:int=1:int=2:int=3: . . . Mixed parameter sets follow the same model: mixed_param_set:int=1:boolean=true:string=a short string: . . . After In the PSM ASCII Mapping parameter sets may be defined by the additional use of colons. For example an array of integers would be represented as follows: param:int[3]:int=1,int=2,int=3 Mixed parameter sets follow the same model: mixed_param_set:set_type=param_1:int=1,param_2:boolean=true,param_3:string=a short string,…
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12769: No discussion of escaping or quoting characters in the ASCII PSM (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

Need to define a standard way to escape and/or quote characters in string types

Resolution: A new section (8.1.2 Reserved Words and Special Characters) will be added to discuss the requirements regarding any special characters and reserved words in the ASCII PSM.
Revised Text: Added new section 8.1.2 at line 1503. Section is as follows. 8.1.2 Reserved Words and Special Characters Reserved Words and Special Characters The following words are reserved and should not be used as parameter or target names: "|GEMS" and "|END|" The following characters are special but can be escaped with a forward slash "/" when used in string parameter values: "|" ","
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12770: 9.1.2 Figure in 9.1.2 uses RTL instead of GEMS (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The figure shows RTL instead of GEMS. Need to correct the figure.

Resolution: Replace the figure with a correct version.
Revised Text: In section 8.1.2 replace figure with the following one:
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12771: 9.2.2 Section 9.2.2: The example shows an incorrect message type (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

The section provides a disconnect example, but the example has a connect message

Resolution: The example will be changed to demonstrate a disconnect message in the GEMS-ASCII PSM.
Revised Text: In section 8.2.2 replace example Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|CON|NORMAL_TERMINATION|END After Replace the token |CON| with |DISC|
Actions taken:
August 8, 2008: received issue
April 30, 2009: closed issue

Issue 12772: Sections 9.2.6 & 9.2.7 (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 9.2.6 and 9.2.7: Example response has an extra (typo) parameter. Need to remove the |0| field before the END.

Resolution: These serve no purpose and are probably just typos. The typos will be fixed.
Revised Text: In section 8.2.6 replace LoadConfigMessage Example Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|LOAD-R|SUCCESS|Desc|100|0|END After GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|LOAD-R|SUCCESS|Desc|100|END In section 8.2.7 replace DirectiveMessage Example Before GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|DIR-R|SUCCESS|Desc|sendVehicleCommand|1|0|accepted:bool=true|END After GEMS|01|000122|123|CS123|T05:011:16:30:00:000:000|FrameSync1|DIR-R|SUCCESS|Desc|sendVehicleCommand|1|accepted:bool=true|END
Actions taken:

Issue 12966: Need an example of how to represent a parameter array in the GEMS-XML PSM (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Need an example of how to represent a parameter array in the GEMS-XML PSM

a.       This missing example was found during our document review

b.      Reported by RT Logic

Resolution: This type of example is not suited to stand alone. Instead one of the existing examples will be modified to include an array of parameters for the purposes of demonstrating this concept.
Revised Text: In section 7.2.3 replace paragraph 1 Before The following is an example of a SetConfigMessage and its response. After The following is an example of a SetConfigMessage and its response. This example sends three parameters to be set. The last parameter provides an example of an array of values. In section 7.2.3.1 replace XML example Before <SetConfigMessage xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="2" token="CS12345" target="/SystemA/FrameSync1" gems_version="1"> <Parameter name="frame_length_in_bits"> <long>1024</long> </Parameter> <Parameter name="sync_pattern"> <hex_value bit_length="22">faf320</hex_value> </Parameter> </SetConfigMessage> After <SetConfigMessage xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" transaction_id="2" token="CS12345" target="/SystemA/FrameSync1" gems_version="1"> <Parameter name="frame_length_in_bits"> <long>1024</long> </Parameter> <Parameter name="sync_pattern"> <hex_value bit_length="22">faf320</hex_value> </Parameter> <Parameter name="telemetry_ports"> <int>10001</int> <int>10002</int> <int>10003</int> </Parameter> </SetConfigMessage>
Actions taken:
October 22, 2008: received issue
April 30, 2009: closed issue

Issue 12967: Add XML and ASCII as normative references (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Add XML and ASCII as normative references

Resolution: Fill in section 3 with normative references for XML and ASCII.
Revised Text: In section 3 fill in as follows XML Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, and Eve Maler, editors. Extensible Markup Language (XML) 1.0 (Fourth Edition). World Wide Web Consortium, 2000. (See http://www.w3.org/TR/2006/REC-xml-20060816.) ASCII American National Standard for Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Change (7-Bit ASCII), ANSI X3.4-1986, American National Standards Institute, Inc,, March 26, 1986
Actions taken:
October 22, 2008: received issue
April 30, 2009: closed issue

Issue 12968: VALID_RANGE description contains extra copy of message UML image (gems-ftf)

Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary:

VALID_RANGE description contains extra copy of message UML image

a.       This was found during our document review

b.      Section 6.3.2.2

c.       Reported by RT Logic

Resolution: Remove the offending duplicate diagram from the INVALID_RANGE description.
Revised Text: Remove the duplicate image from document.
Actions taken:
October 22, 2008: received issue
April 30, 2009: closed issue

Issue 13133: header of the GEMS_base_types.xsd file does not match with section 7.1.1 of the GEMS Specification Beta 1 (gems-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:

The header of the GEMS_base_types.xsd file does not match with section 7.1.1 of the GEMS Specification Beta 1 document. A. The new issue was mentioned in the AB review of the GEMS FTF report
B. Reported by Hugues Vincent

Resolution: The GEMS XSD file contains the correct header information. Update section 7.1.1 of the document with the correct header found in this XSD file.
Revised Text: In section 7.1.1 replace all references to "http://www.rtlogic.com/base" with "http://www.omg.org/gems".
Actions taken:
December 2, 2008: received issue
April 30, 2009: closed issue