Issues for AMSM Finalization Task Force 2

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

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

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

Jira Issues

Issue 11404: AMS_Property template (amsm-ftf)

Click here for this issue's archive.
Source: Selex ES (Mr. Fabrizio Morciano, fmorciano(at)selex-si.com)
Nature: Revision
Severity: Significant
Summary:

In the spec the AMS_Property template have been used several times; it has been used in the PIM for instance as: AMS_Property<AMS_StdState,ST_NOSTD> or AMS_Property<AMS_StdMechanism,MS_NONSTD>. Now, it could be useful to always use the same convention to define the names of such �non stardard� enumeration values (such as ST_NOSTD or MS_NONSTD) since sometimes in the document it is used ST_NONSTD instead of ST_NOSTD, or MS_NOSTD instead of MSNONSTD and so on�In this way it would be easier to catch these little inconsistencies. For instance in the diagram 7.16 it is used MS_NONSTD instead of MS_NOSTD... but it is just an example since this kind of error can be found in various parts of the document.

Resolution: Generalize the use of *_NONSTD
Revised Text: Search and replace HU_NOSTD with HU_NONSTD Search and replace HU_NON_STD with HU_NONSTD Search and replace ST_NOSTD with ST_NONSTD Search and replace MS_NOSTD with MS_NONSTD Replace Figure 7.7 on page 37 with the following figure: Replace Figure 7.20 on page 97 with the following figure: Disposition: Resolved
Actions taken:
September 14, 2007: received issue
July 18, 2008: closed issue

Issue 11405: Typo error (AMS_Propoerty instead of AMS_Property). (amsm-ftf)

Click here for this issue's archive.
Source: Selex ES (Mr. Fabrizio Morciano, fmorciano(at)selex-si.com)
Nature: Revision
Severity: Minor
Summary:

Typo error (AMS_Propoerty instead of AMS_Property).

Resolution: Correct the typo error.
Revised Text: Find and replace AMS_Propoerty and AMS_Property.
Actions taken:
September 14, 2007: received issue
July 18, 2008: closed issue

Issue 11406: The numbering of the table is in some cases incorrect (amsm-ftf)

Click here for this issue's archive.
Source: Selex ES (Mr. Fabrizio Morciano, fmorciano(at)selex-si.com)
Nature: Revision
Severity: Minor
Summary:

The numbering of the table is in some cases incorrect� for instance in chapter 7 it starts from 7.4 and in chapter 8 starts from 8.6

Resolution: Modification in the numbering of the tables.
Revised Text: Re-number Table 7.4 (pages 115, 116 and 117) with 7.1, 7.5 (page 112) with 7.2, 8.6 (page 125) with 8.1, 8.7 (page 125) with 8.2, 8.8 (page 126) with 8.3, 8.9 (page 126) with 8.4.
Actions taken:
September 14, 2007: received issue
July 18, 2008: closed issue

Issue 11505: DCPS/f and DCPS/m profiles issue (amsm-ftf)

Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme(at)navy.mil)
Nature: Revision
Severity: Significant
Summary:

Clarification of the intent and approach is requested concerning 1) how the DCPS/f profile will access static configuration information and 2) how the DCPS/m profile when used with the CORBA/IDL and CIM PSMs will map the Subscription methods to DCPS/m topics, i.e., the CORBA/IDL PSM subscription methods currently pass in an object with an interface to receive CORBA one-way callbacks, which would not be needed or used if the DCPS/m profile is used.

Resolution: Point (1): DCPS/f accesses static configuration information through the mandatory XML PSM Point (2): "they work in their usual way, independently of each other"
Revised Text: Replace first bullet of paragraph 11.1.1 with: "The DCPS/f ('/f' stands for full) PSM which relates to the full DCPS PSM as described in this section. This PSM along with the XML PSM is intended to be equivalent to the CORBA/IDL and CIM profile, and thus compliant implementations are not required to deploy any elements of the CORBA and/or CIM profiles. The DCPS/f PSM shall access the static configuration information through the mandatory XML PSM." Replace the second bullet of paragraph 11.1.1 with: "The DCPS/m ('/m' stands for monitoring) PSM which is a subset of the DCPS/f PSM, and contains those elements which are required for asynchronous monitoring of states of the different (software and hardware) elements. The DCPS/m PSM is defined to allow other PSMs (CORBA and/or CIM) to import it and use it for asynchronous monitoring tasks. Note that the inclusion of DCPS/m profile in CORBA and/or CIM PSM is not a mandatory, but an optional (convenience) mechanism. Whenever the DCPS/m profile is implemented along with CORBA and/or CIM PSM, the CORBA and/or CIM profile work in their usual way, independently of the DCPS/m profile."
Actions taken:
September 21, 2007: received issue
July 18, 2008: closed issue

Issue 11506: Section: 7.1.8 (amsm-ftf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme(at)navy.mil)
Nature: Enhancement
Severity: Significant
Summary:

Clarification of capabilities for control of J2EE and CCM applications is requested.

Resolution: The resolution does not require a change in the spec, it is an implementation detail: a set of CIM_Action(s) needs to be inserted to drive the CCM start (see image below).
Revised Text:
Actions taken:
September 21, 2007: received issue
July 18, 2008: closed issue

Discussion:

close, no change

Issue 11507: Section: 7.1.9.36 (amsm-ftf)

Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme(at)navy.mil)
Nature: Clarification
Severity: Significant
Summary:

Clarification is needed that the CIM_Process Handle/key is the Process ID (pid). This is implied but not explicitly stated. Likewise, clarification is requested in Section 7.1.9.50 to state that the CIM_Thread Handle/key is the Operating System Thread ID.

Resolution: On POSIX systems, this attribute is the process ID (resp. thread) On Win32 systems, this attribute is the process handle (resp. thread)
Revised Text: Section 7.1.9.36, replace the 1st bullet with: � "Handle:" A string used to identify the Process. On POSIX systems, this attribute is the process ID. On Win32 systems, this attribute is the process handle. Section 7.1.9.50, replace the 1st bullet with: � "Handle:" A string used to identify the Thread. On POSIX systems, this attribute is the thread ID. On Win32 systems, this attribute is the thread handle.
Actions taken:
September 21, 2007: received issue
July 18, 2008: closed issue

Issue 11508: Section: 7.1.3.2 (amsm-ftf)

Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme(at)navy.mil)
Nature: Enhancement
Severity: Significant
Summary:

The CIM_Action that the error is associated with should be added to the AMS_ErrorStruct (Section 2.4.2.4) so that it will be clear which Action failed. This is important for determining where a problem occurred within a set of actions.

Resolution: Precise in the CIM_ActionStruct class that the attribute "Element" must be the full path to the action that caused the error when the error comes from the execution of an action.
Revised Text: Replace the last bullet of the bullet list of paragraph 7.1.3.4 with the following: � The element that caused the error referenced by a string that contains the full name of this element. When an action fails to be executed, this attributes gives a reference to the CIM_Action that actually fails.
Actions taken:
September 21, 2007: received issue
July 18, 2008: closed issue

Issue 11509: Section: 7.1.11.10 (amsm-ftf)

Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme(at)navy.mil)
Nature: Enhancement
Severity: Significant
Summary:

The specific set of HW Utilizations and semantics should be reviewed to remove ambiguities. In particular, the time scale over which utilizations are measured should be explicitly stated. In addition, the specific set of HW Utilizations should be reviewed to determine whether additional information is needed, e.g., 1) network data input and output values and rates. 2) Per cpu statistics, 3) per network connection statistics, 4) page faults and rates, 5) size of the process ready queue, etc...

Resolution: Add a new template sub-classing AMS_Property to have the ability to accounts hardware and software resource usage with time, duration and units; and use it in AMS_Host and AMS_LANEndPoint.
Revised Text: Pages 97, 98: Replace Fig. 7.20 (Network class diagram (1/2)) with: Replace Fig. 7.21 (Network class diagram (2/2)) with: Page 103: In the paragraph of the section 7.1.10.5 (AMS_Host Class) just before the table, replace "AMS_Property" with "AMS_Accounting". In the table of the section 7.1.10.5 (AMS_Host Class), replace "AMS_Property" with "AMS_Accounting". Page 103: Add the following paragraph just before the table of the section 7.1.10.6 (AMS_LANEndPoint Class): It has also an association to AMS_Accounting<AMS_StdHWUtilisation,HU_NONSTD> in order to design platform-specific hardware utilizations (cf. AMS_StdHWUtilisation for the normalized set of platform-specific hardware utilizations). In the table of the same section, add the following lines: Associations Multiplicity Class AMS_RTHU <<optional HSM>> 0 .. * AMS_Accounting<AMS_StdHWUtilisation,HU_NONSTD> Pages 104, 105: In the enumeration in the section 7.1.10.10 (AMS_StdHWUtilisation class), replace the bulleted list with the following items: � HU_NONSTD: special value that denotes a non-normalized value (i.e. use the "Name" attribute instead. � HU_CPU: The amount of time the CPU was occupied during the measurement interval. � HU_RUNQ: Average run queue length over the measurement interval. � HU_WAIT: The amount of time, processes had to wait for IO during the measurement interval. � HU_LAN_BTX: The amount of bytes sent via the LAN endpoint transmitter during the measurement interval. � HU_LAN_BRX: The amount of bytes received via the LAN endpoint receiver during the measurement interval. � HU_LAN_PTX: The amount of packets sent via the LAN endpoint transmitter during the measurement interval. � HU_LAN_PRX: The amount of packets received via the LAN endpoint receiver during the measurement interval. � HU_PMS: The amount of occupied Physical Memory Space. � HU_PFS: The amount of occupied Paging File Space. � HU_DSK_WR: The amount of bytes written to disk during the measurement interval. � HU_DSK_RD: The amount of bytes read from disk during the measurement interval. � HU_OFS: The amount of bytes, of the file systems, that is occupied. � HU_FS: The amount of bytes of the file systems. � HU_PN: number of running processes. � HU_TN: number of running threads. Page 112 and following pages: Replace Fig. 7.26 (AMS_Property template class diagram) with: Add a new section 7.1.12.1 "AMS_Accounting<Class T, T v> Template": The AMS_Accounting template adds to the AMS_Property value-name pairs the following data: � Capability: Maximum capability for the property. An empty string denotes unrestricted capability. � Time: Expresses the time the measurement was finished. � Duration: Duration of the measurement interval in micro seconds. A value of 0 denotes a sample of absolute value. � Units: The units in which the Value is expressed. Standardized values are: o Time standardized values: � ns (nanoseconds) � us (microseconds) � ms (milliseconds) � s (seconds) o Memory size standardized values: � B (byte) � kB (kilobyte) � MB (megabyte) � GB (gigabyte) � TB (terabyte) This template provides the ability to accounts hardware and software resource usage. Attributes Type Capability String Time String Duration uint32 Units String Page 162 and following ones: In section 8.6.9 (AMS_LogicalHardware.idl), find and replace "Property" with "Accounting". In the interface "AMS_Accounting_StdHWUtilisation", add the following attributes: attribute string Capability; attribute string Time; attribute AMS_Util::AMS_uint32 Duration; attribute string Units; In the interface "AMS_LANEndPoint", add the following attribute and function: AMS_Accounting_StdHWUtilisationListIterator GetStdHWUtilisationListIterator ( ); readonly attribute AMS_Accounting_StdHWUtilisationList RTHU; Replace the enum "AMS_StdHWUtilisation" with the following: enum AMS_StdHWUtilisation { HU_NONSTD, HU_CPU, HU_RUNQ, HU_WAIT, HU_LAN_BTX, HU_LAN_BRX, HU_LAN_PTX, HU_LAN_PRX, HU_PMS, HU_PFS, HU_DSK_WR, HU_DSK_RD, HU_OFS, HU_FS HU_PN, HU_TN } Page 206 and following ones: In section 9.6.8 ("Logical Hardware"), find and replace "Property" with "Accounting". In the complex type "AMS_Accounting_StdHWUtilisationType", add the following attributes: <xsd:attribute name="Capability" type="xsd:string" use="required" /> <xsd:attribute name="Time" type="xsd:string" use="required" /> <xsd:attribute name="Duration" type="xsd:int" use="required" /> <xsd:attribute name="Units" type="xsd:string" use="required" /> In the complex type "AMS_LANEndPointType", add the following lines just before the line with "</xsd:extension>": <xsd:sequence> <xsd:element name="AMS_RTHU" type="AMS_RTHU_LinkType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> Replace the simple type "AMS_StdHWUtilisation" with: <xsd:simpleType name="AMS_StdHWUtilisation"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="HU_NONSTD" /> <xsd:enumeration value="HU_CPU" /> <xsd:enumeration value="HU_RUNQ"/> <xsd:enumeration value="HU_WAIT"/> <xsd:enumeration value="HU_LAN_BTX"/> <xsd:enumeration value="HU_LAN_BRX"/> <xsd:enumeration value="HU_LAN_PTX"/> <xsd:enumeration value="HU_LAN_PRX"/> <xsd:enumeration value="HU_PMS"/> <xsd:enumeration value="HU_PFS"/> <xsd:enumeration value="HU_DSK_WR"/> <xsd:enumeration value="HU_DSK_RD" /> <xsd:enumeration value="HU_OFS" /> <xsd:enumeration value="HU_FS" /> <xsd:enumeration value="HU_PN" /> <xsd:enumeration value="HU_TN" /> </xsd:restriction> </xsd:simpleType> Page 259 and following ones: In section 10.1.4.6 (Logical Hardware), find and replace "Property" with "Accounting". In section 10.1.4.6 (Logical Hardware), just after the first 'pragma', add the following lines: //================================================================== // Accounting //=================================================================== [Description ("")] class AMS_Accounting { [Key] string InstanceID; string Name; string Value; string Capability; string Time; uint32 Duration; string Units; }; Replace the definition of class AMS_RTHU at the end of the section 10.1.4.6 (Logical Hardware) with the following one: //=================================================================== // RTHU //=================================================================== [Association, Aggregation, Description("An association between" "AMS_Accounting<AMS_StdHWUtilisation, HU_NONSTD> class in order" "to design platform-specific hardware utilisation.")] class AMS_RTHU : CIM_Dependency { [Key, aggregate, Override("Antecedent"), Max(1), Min(1)] AMS_Host REF Antecedent; [Overrride("Dependent")] AMS_Accounting REF Dependent; ValueMap { "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"}, Values { "HU_NONSTD", "HU_CPU", "HU_RUNQ", "HU_WAIT", "HU_LAN_BTX", "HU_LAN_BRX", "HU_LAN_PTX", "HU_LAN_PRX", "HU_PMS", "HU_PFS", "HU_DSK_WR", "HU_DSK_RD", "HU_OFS", "HU_FS", "HU_PN", "HU_TN"}] uint16 AMSStdHWUtilisation; }; At the end of the section 10.1.4.6 (Logical Hardware), add the following lines: //=================================================================== // RTHU_LAN //=================================================================== [Association, Aggregation, Description("")] class AMS_RTHU_LAN : CIM_Dependency { [Key, aggregate, Override("Antecedent"), Max(1), Min(1)] AMS_LANEndPoint REF Antecedent; [Overrride("Dependent")] AMS_Accounting REF Dependent; ValueMap { "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11"}, Values { "HU_NONSTD", "HU_CPU", "HU_RUNQ", "HU_WAIT", "HU_LAN_BTX", "HU_LAN_BRX", "HU_LAN_PTX", "HU_LAN_PRX", "HU_PMS", "HU_PFS", "HU_DSK_WR", "HU_DSK_RD", "HU_OFS", "HU_FS", "HU_PN", "HU_TN"}] uint16 AMSStdHWUtilisation; }; Page 281 and following ones: In section 11.1.6, find and replace Property with Accounting. In section 11.1.6, replace the "struct AMS_PropertyStdHWUtilisation" block and following pragma line with the following lines: // struct AMS_AccountingStdHWUtilisation { // string Name; AMS_StdHWUtilisation StdName; // string Value; string Capability; string Time; long Duration; string Units; }; #pragma keylist AMS_AccountingStdHWUtilisation Name,StdName In section 11.1.6, in the "struct AMS_LANEndPoint" block, add the following lines: // AMS_Accounting<AMS_StdHWUtilisation, HU_NONSTD> sequence<AMS_AccountingStdHWUtilisation> AMS_RTHU; In section 11.1.6, replace the "enum AMS_StdHWUtilisation" with: enum AMS_StdHWUtilisation { HU_NONSTD, HU_CPU, HU_RUNQ, HU_WAIT, HU_LAN_BTX, HU_LAN_BRX, HU_LAN_PTX, HU_LAN_PRX, HU_PMS, HU_PFS, HU_DSK_WR, HU_DSK_RD, HU_OFS, HU_FS HU_PN, HU_TN }
Actions taken:
September 21, 2007: received issue
July 23, 2009: closed issue

Discussion:

Full study of these points need more time.

Issue 11516: Update reference (amsm-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Light weight logging specification (realtime/2002-06-14) referenced is not newest version. Possible solution: Use the formal/05-02-02.

Resolution: Use the formal/05-02-02
Revised Text: Page 5, 5th bullet: replace "realtime/2002-06-14" with "formal/05-02-02".
Actions taken:
September 26, 2007: received issue
July 18, 2008: closed issue

Issue 11517: PSM DCPS (amsm-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

PSM DCPS: Root topics are not needed because the lists can be retrieved from other topics. This would give redundant info in the system and unnecessary overhead. For example for software systems no root topic Software systems is needed. The list of software systems are accessible via SoftwareSystem topic. Proposed solution: Remove all info related to the root topics.

Resolution: Remove all info related to the root topics.
Revised Text: Section 11.1.1.1, replace the 1st line with: There are three 'types' of AMSM topics: Section 11.1.1.1, delete the last bullet of the page (starting with "The root topics type �"). Section 11.1.1.2, delete the bullet starting with "The root topics have�" and the table below (table 11.1). Rename following tables (11.2 to 11.8) in consequence. Remove all the section 11.1.1.5.4 "Root Topics Data Type". Section 11.1.5, replace the last bullet with: The DCPS/m ('/m' stands for monitoring) relates to the "element topics" and "indication topics" - i.e., all of them but "control topics." DCPS/m profile is therefore a subset of the DCPS/f profile. Section 11.1.6, remove all lines between // root topics (included) and // Indication topics (excluded)
Actions taken:
September 26, 2007: received issue
July 18, 2008: closed issue

Issue 11518: Add prefix to the topic names (amsm-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Add prefix to the topic names, because they are global and should be unique within the whole system. B.t.w.: For the type definitions the prefix is not necessary because the are in the namespace AMSM. Proposed solution: Add Prefix AMS or CIM to Topic names. Topic name = Data type name

Resolution: Add Prefix AMS to Topic names
Revised Text: In Section 11.1.1.2, replace the first bullet with: The name of an "element topic" is the concatenation of "AMS_" and the name of the class of the corresponding AMSM object. In Section 11.1.1.2, replace the names in the first column of the second table by (in the same order): AMS_CT_LoadConfiguration, AMS_CT_UnloadConfiguration, AMS_CT_ShutDownESE, AMS_CT_CreateHardwareGroup, AMS_CT_ShutDown, AMS_CT_StartUp, AMS_CT_StartUpOnHost, AMS_CT_StartUpOnSpec, AMS_CT_ActivateAsPrimary, AMS_CT_ForceShutDown, AMS_CT_Load, AMS_CT_Stop, AMS_CT_ClearLog, AMS_ControlResponse In Section 11.1.1.5.5, replace the first line with: " "Control topics" have specific data types which names are the same as the topic names (cf. table in paragraph 11.1.1.2).", and remove the following table. In the reminder of the paragraph 11.1.1.5.5, replace "ControlResponse" with "AMS_ControlResponse"). In Section 11.1.1.5.5, replace the last code snippet with: struct AMS_ErrorStruct { // message string Message; // errno long Number // error code AMS_ErrorCode Code; // full path to the element string Element }; struct AMS_ControlResponse { // identifier of the request long request_id; // the ErrorStruct AMS_ErrorStruct Error; } #pragma keylist AMS_ControlResponse request_id
Actions taken:
September 26, 2007: received issue
July 18, 2008: closed issue

Issue 11519: Vista is missing in the OS type enumeration (amsm-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Vista is missing in the OS type enumeration. Proposed solution: Replace the enumeration of the OS type to a string, because it will be changed in the future many times. And it than easy to a add an OS type, at least for the DCPS PSM.

Resolution: Add vista to the OS type enumeration
Revised Text: Add the item "Windows Vista" at the end of the enumerations: � "TargetOperatingSystem" in paragraph 7.1.9.1 � "TargetOperatingSystem" in paragraph 7.1.9.32 � In paragraph 7.1.9.33 In paragraph 8.6.11, replace the first occurrence of "z_OS" with "z_OS, WindowsVista". In paragraph 9.6.10, add after the first occurrence of "<xsd:enumeration value="z/OS" />" the following line: <xsd:enumeration value="Windows Vista" /> In paragraph 11.1.6, replace the first occurrence of "z_OS" with "z_OS, WindowsVista".
Actions taken:
September 26, 2007: received issue
July 18, 2008: closed issue

Issue 11613: Section: 7.1.5 (amsm-ftf)

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

Paragraph 7.1.5 ("AMS_BAlancingStyle") should be numbered 7.1.4.2.

Resolution: Paragraph 7.1.5 is to be numbered 7.1.4.2
Revised Text: Renumber the section "AMS_BalancingStyle class" (page 42) with 7.1.4.2 and the following section accordingly.
Actions taken:
October 15, 2007: received issue
July 18, 2008: closed issue

Discussion:

Issue 13035: Errors in AMSM.idl (amsm-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Errors in AMSM.idl: Line 81: Undefined fields in keylist (remove ",CPULoad,MemoryLoad,DskUsage") Line 118: Missing ";" at EOL Line 120: Missing ";" at EOL Line 122: Keylist is defined of an missing structure, insert before line 122: struct AMS_ControlResponse { // identifier of the request long request_id; // the ErrorStruct AMS_ErrorStruct Error; }; Line 154: typo "sequance" must be "sequence" Line 199: typo "sring" must be "string" Line 365: missing prefix "AMS_" before "LOAD_START_DIRTY" Line 372: AMS_State used before it is defined (used on line 154) Line 382: typo "AMS_StdMechanisms" should be "AMS_StdMechanism" Line 44, Line 466, Line 496, Line 524, Line 541, Line 561: Missing ";" at EOL Line 592, Line 594,Line 605,Line 607,Line 613: "list" must be "sequence" Line 635, Line 660, Line 695, Line 722, Line 733, Line 744, Line 755, Line 770, Line 781, Line 792, Line 803, Line 814, Line 825, Line 836, Line 847, Line 865, Line 906, Line 937, Line 954, Line 1153, Line 1171: Missing ";" at EOL

Resolution: All these issues are syntactic errors.
Revised Text: n Section 11.1.6: Replace the line with "#pragma keylist AMS_RTHWIndication" with: #pragma keylist AMS_RTHWIndication AMS_NetworkElt In the "struct AMS_ErrorStruct" block, add a ";" at the end of the lines "long Number" and "string Element". Insert before the line "#pragma keylist AMS_Response request_id", the following snippet: struct AMS_ControlResponse { // identifier of the request long request_id; // the ErrorStruct AMS_ErrorStruct Error; }; Find and replace "sequance" with "sequence", "sring" with "string", "LOAD_START_DIRTY" with "AMS_LOAD_START_DIRTY", "AMS_StdMechanisms" with "AMS_StdMechanism", "list<string>" with "sequence<string>". Move the "enum AMS_State" block between the lines "// Control topics" and " enum AMS_ErrorCode {". In the "struct AMS_Application", "struct AMS_ExecutableSoftwareElement", "struct AMS_RedundancyGroup", "struct AMS_LoadBalancingGroup", "struct AMS_DeploymentLink", "struct CIM_IPProtocolEndPoint", "struct CIM_NextHopRoute", "struct CIM_ProtocolEndPoint", "struct CIM_LogicalDisk", "struct CIM_Memory", "struct CIM_PowerSupply", "struct CIM_Watchdog", "struct CIM_Processor", "struct CIM_LogicalPort", "struct CIM_NetworkPort", "struct CIM_EthernetPort", "struct CIM_Display", "struct CIM_Sensor", "struct CIM_StorageExtent", "struct CIM_ConnectivityCollection", "struct CIM_EthernetPortStatistics", "struct CIM_LANEndPoint", "struct CIM_NextHopIPRoute", "struct CIM_RemoteServiceAccessPoint", "struct CIM_ServiceAccessPoint", "struct AMS_OperatingSystem", "struct AMS_LANEndPoint" blocks, add ";" at the end of the lines "string Owner".
Actions taken:

Issue 13036: States like HALTED can not be realized as easy on platforms like VxWorks (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

States like HALTED can not be realized as easy on platforms like VxWorks. For a single task this is easy, but GNATworks based applications can be multithreaded (thus have a process like model). Supporting a HALTED state for GNATworks on VxWorks would require a special profile to be supported. This state must be made optional.

Resolution: Move the HALTED state from the Normal Package to the Maximum Control Package as long as the matching functions and transitions
Revised Text: Page 37: In section 7.1.4, replace the figure 7.7 ("Application class diagram (1/3)") with the following one: Page 44: In the 19th, 21st and 22nd row of the table of the section 7.1.4.3 (marked as "Load", "Stop" and "Continue"), add the following text in the first column: <<optional MC>>. At the end of the paragraphs 7.1.4.3.2 ("Continue") and 7.1.4.3.9 ("Stop"), add the following line: This method is optional ("Maximum Control" profile). Page 118 and following: Replace the figure 7.27 with the following one: In paragraph 7.1.14.1.4 ("Running"), replace the cell in the first row, second column with the following text: Halt the execution of the Software Element (e.g., a SIGSTOP on Unix). This transition is optional ("Maximum Control" profile). In paragraph 7.1.14.1.5 ("Halted"), add the following line before the line "Transitions": This state and its transitions are optional ("Maximum Control" profile).
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13038: Transition CONTINUE (see fig 7.27) is missing (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Transition CONTINUE (see fig 7.27) is missing. The description of transition STOP_HALTED does match transition CONTINUE but not STOP_HALTED (see Stopped state in 7.1.14.1.6).

Resolution: The description of the transition CONTINUE is to be added and the description of the transition STOP_HALTED must be fixed.
Revised Text: Page 120; replace the table of the section 7.1.14.1.5 with the following one: CONTINUE A request to resume execution of the Software Element (e.g., a SIGCONT on Unix). STOP_HALTED Stop the Software Element when in the HALT state.
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13039: Strange relation between methods and transitions (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Strange relation between methods and transitions. The expected state and the methods to use to reach the state depend on the previous state. That is very strange and error prone. e.g. if the wanted state is STOPPED, case the current state is RUNNING, ShutDown must be called. In case the state is HALTED, Stop must be called.The method should denote the wanted state with this limitation that only specified state transitions are possible. Note that there is no operation to enter the HALT state. "

Resolution: Agree. Let's summarize: the StartUp methods are for reaching state "RUNNING" (transitions LOAD_START, START, LOAD_START_DIRTY; CONTINUE is lacking here), the Shutdown methods are for reaching state "EXECUTABLE" (transitions UNLOAD, RECOVER, RECOVER_DIRTY; STOP have to be removed here), the Load method reaches the state "LOADED" (transitions LOAD, LOAD_DIRTY), the Stop method reaches the "STOPPED" state (transitions HALT, STOP_HALTED; HALT should be replaced by STOP here), and the "Continue" method is a shorthand to reach the state "RUNNING" from the state "HALTED". Eventually, the state "HALTED" is no more reachable and a method "halt" has so to be added to reach it".
Revised Text: Page 37: Replace the figure 7.7 ("Application class diagram (1/3)") with the following: Page 44: In the table of the section 7.1.4.3, add the following line just after the "Operations" line: halt return type unit16 And add a new paragraph 7.1.4.3.1 "Halt ()" (and rename the following ones 7.1.4.3.x): This operation stops the executable software element. It shall return: o AMS_RESOURCEERROR if the element could not be stopped on account of an OS resource starvation error (lack of memory, disk) when performing one of the actions of the associated specification. o AMS_RIGHTERROR if the element could not be stopped on account of an OS right error when performing one of the actions of the associated specification. o AMS_BADSTATE if the element is not in a state in which it could be halted. o AMS_HALTFAILED if the element could not be halted for any other reason. In all case of error, a full explanation of the cause of the error shall be logged. After an error, the executable software element remains in which it was before the execution of the method. Page 121: Replace the table 7.5 ("Mapping between ESE methods and transitions) of the section 7.1.14.2 ("Mapping between ESE transitions and methods") with the following one: Methods Transitions StartUp, StartUpOnSpec, StartUpOnHost LOAD_START, START, LOAD_START_DIRTY ShutDown, ForceShutDown UNLOAD, RECOVER, RECOVER_DIRTY Load LOAD, LOAD_DIRTY Stop STOP, STOP_HALTED Continue CONTINUE Halt HALT Page 116: In the Table 7.4 ("Error Codes"), add the following ones between the AMS_BADSTATE and AMS_STARTFAILED lines: AMS_HALTFAILED The AMS_ExecutableSoftwareElement::Halt method failed for an unknown reason (see log). Page 129: In section 8.6.1 ("AMS_Util.idl"), in the enum "AMS_ErrorCode", add the following snippet between the AMS_BADSTATE and AMS_STARTFAILED lines: AMS_HALTFAILED, Page 139: In section 8.6.4 ("AMS_Application.idl"), in the interface "AMS_ExecutableSoftwareElement", after the line "void Continue ( ) raises (AMS_Util::AMS_Error);", add the following snippet: void Halt ( ) raises (AMS_Util::AMS_Error); Page 241: In section 10.1.4.2 ("Application"), after the line "uint16 Continue();", add the following snippet: [Description ("This operation halts the executable software" "element.")] uint16 Halt(); Page 282: In section 11.1.6 ("Mapping"), in the enum "AMS_ErrorCode", add the following snippet between the AMS_BADSTATE and AMS_STARTFAILED lines: AMS_HALTFAILED, Page 285: In section 11.1.6 ("Mapping"), after the line "#pragma keylist AMS_CT_Continue Element", add the following snippet: // struct AMS_CT_Halt { // identifier of the request long request_id; // the element to be controled string Element; // the attributes (cf. PIM) }; #pragma keylist AMS_CT_Halt Element
Actions taken:
October 31, 2008: received issue
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13040: Separate topic for CurrentState: (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Separate topic for CurrentState: The AMS_ExecutableSoftwareElement CurrentState aggregation is mapped in an AMS_State enumeration within the struct of AMS_ExecutableSoftwareElement. The CurrentState state however will evolve asynchronously from the state of other attributes. Further it is very likely that control over the CurrentState is located somewhere else. For that reason it is more practical to define a separate topic which via a weak reference will identify the state of the AMS_ExecutableSoftwareElement. Note: This statement is probably true for more state/statistics based information.

Resolution: Separate the CurrentState attribute for the sake of the ease of implementability.
Revised Text: n section 11.1.1, page 289, replace the following snippet: // struct AMS_ExecutableSoftwareElement { // the full name of an element of AMS_SoftwareSystem // the full name of an element of AMS_Application string Owner; // sequence of full names of elements of AMS_Application sequence<string> CIM_SystemComponent; // the full name of an element of AMS_ESESpec string CIM_SoftwareElementServiceImplementation; // AMS_State CurrentState; // sequence of full names of elements of AMS_RedundancyGroup // sequence of full names of elements of AMS_LoadBalancingGroup sequence<string, 1> CIM_RedundancyComponent; // AMS_RTSoftwareStatus Status; // AMS_RedundancyEltState RedState; // the full name of an element of AMS_DeploymentLink string AMS_ESEDeployed; // string Name; // platform-specific states sequence<AMS_PropertyStdState> AMS_SpecificStates; // sequence of full names of CIM_Process sequence<string> CIM_ServiceProcess; }; #pragma keylist AMS_ExecutableSoftwareElement Name,Owner With: // struct to handle the states of the ESEs that evolve more // dynamically than the rest than the rest of its ESE. // The owner is the ESE itself and there is just one state by ESE // see OMG issue 13040 struct AMS_StateOfExecutableSoftwareElement { // the full name of an element of AMS_ExecutableSoftwareElement string Owner; // AMS_State current; }; #pragma keylist AMS_StateOfExecutableSoftwareElement Owner // struct AMS_ExecutableSoftwareElement { // the full name of an element of AMS_SoftwareSystem // the full name of an element of AMS_Application string Owner; // sequence of full names of elements of AMS_Application sequence<string> CIM_SystemComponent; // the full name of an element of AMS_ESESpec string CIM_SoftwareElementServiceImplementation; // the full name to fetch the state string CurrentState; // sequence of full names of elements of AMS_RedundancyGroup // sequence of full names of elements of AMS_LoadBalancingGroup sequence<string, 1> CIM_RedundancyComponent; // AMS_RTSoftwareStatus Status; // AMS_RedundancyEltState RedState; // the full name of an element of AMS_DeploymentLink string AMS_ESEDeployed; // string Name; // platform-specific states sequence<AMS_PropertyStdState> AMS_SpecificStates; // sequence of full names of CIM_Process sequence<string> CIM_ServiceProcess; }; #pragma keylist AMS_ExecutableSoftwareElement Name,Owner
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13041: QoS not defined correctly (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

QoS not defined correctly: The section uses the term "topics QoS" incorrectly. In DDS, Topic, DataReader and DataWriter QoS setting are defined independent of each other. This chapter incorrectly merges all QoS policies into one merged list. This should at least not be called topics QoS.

Resolution: Reshape the section about QoS for the DCPS mapping.
Revised Text: Replace the section 11.1.1.4 with the following one: 11.1.1.4 QoS Policy settings Policy values can be "unspecified", meaning that the correct value can only be determined at system design and integration level. The policy is either significant at system design level, for instance communication priority related to other topics, or not significant at all. Policy values can be "implementation defined". The specific implementation or product must make a choice that best fits it's situation. In general, DESTINATION_ORDER policy BY_SOURCE_TIMESTAMP is selected. This selection makes sure that finally a consistent state in the distributed DataReader databases in case of order reversal and/or different transport latencies exists. The DDS will store the sample with the latest timestamp (case HISTORY depth is set to 1) independent in which order the samples arrive. An sufficient accurate time alignment between hosts is needed in order to facilitate this selection. 11.1.1.4.1 General QoS Policy settings The general QoS setting are applicable to the DDS entities DomainParticipantFactory, DomainParticipant, Publisher and Subscriber involved in the publication and subscription of all element, indication and control topics. 11.1.1.4.1.1 DomainParticipantFactory Table 11.2 DomainParticipantFactory QoS Policies QoS policy Attribute Value ENTITY_FACTORY autoenable_created_entities unspecified 11.1.1.4.1.2 Participant Table 11.3 Participant QoS Policies QoS policy Attribute Value USER_DATA value unspecified ENTITY_FACTORY autoenable_created_entities unspecified 11.1.1.4.1.3 Publisher Table 11.4 Publisher QoS Policies QoS policy Attribute Value GROUP_DATA value unspecified ENTITY_FACTORY autoenable_created_entities unspecified PRESENTATION access_scope INSTANCE_PRESENTATION coherent_access FALSE ordered_access FALSE PARTITION name implementation defined 11.1.1.4.1.4 Subscriber Table 11.5 Subscriber QoS Policies QoS policy Attribute Value GROUP_DATA value unspecified ENTITY_FACTORY autoenable_created_entities unspecified PRESENTATION access_scope INSTANCE_PRESENTATION coherent_access FALSE ordered_access FALSE PARTITION name implementation defined 11.1.1.4.2 Topic QoS Policies Topic QoS policies are defined per Element, Indication and Control topic category. 11.1.1.4.2.1 Element topic Table 11.6 Element topic, Topic QoS Policies QoS policy Attribute Value TOPIC_DATA value unspecified DURABILITY kind TRANSIENT DURABILITY_SERVICE service_cleanup_delay implementation defined history_kind KEEP_LAST history_depth 1 max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED DEADLINE period INFINITE LATENCY_BUDGET duration unspecified LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind RELIABLE max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth 1 RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TRANSPORT_PRIORITY value unspecified LIFESPAN duration INFINITE OWNERSHIP kind SHARED 11.1.1.4.2.2 Indication topic Table 11.7 Indication topic, Topic QoS Policies QoS policy Attribute Value TOPIC_DATA value unspecified DURABILITY kind VOLATILE DURABILITY_SERVICE service_cleanup_delay unspecified history_kind unspecified history_depth unspecified max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED DEADLINE period INFINITE LATENCY_BUDGET duration unspecified LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind RELIABLE max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth 1 RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TRANSPORT_PRIORITY value unspecified LIFESPAN duration INFINITE OWNERSHIP kind SHARED 11.1.1.4.2.3 Control topic Table 11.8 Control topic, Topic QoS Policies QoS policy Attribute Value TOPIC_DATA value unspecified DURABILITY kind VOLATILE DURABILITY_SERVICE service_cleanup_delay unspecified history_kind unspecified history_depth unspecified max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED DEADLINE period INFINITE LATENCY_BUDGET duration unspecified LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind RELIABLE max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth implementation defined RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TRANSPORT_PRIORITY value unspecified LIFESPAN duration INFINITE OWNERSHIP kind SHARED 11.1.1.4.3 DataReader QoS Policies DataReader QoS policies are defined per Element, Indication and Control topic category. 11.1.1.4.3.1 Element topic Table 11.9 Element topic, DataReader QoS Policies QoS policy Attribute Value USER_DATA value unspecified DURABILITY kind VOLATILE DEADLINE period INFINITE LATENCY_BUDGET duration INFINITE LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind BEST_EFFORT max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth 1 RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TIME_BASED_FILTER minimum_separation 0 READER_DATA_LIFECYCLE autopurge_nowriter_samples_delay INFINITE autopurge_disposed_samples_delay implementation defined 11.1.1.4.3.2 Indication topic Table 11.10 Indication topic, DataReader QoS Policies QoS policy Attribute Value USER_DATA value unspecified DURABILITY kind VOLATILE DEADLINE period INFINITE LATENCY_BUDGET duration INFINITE LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind BEST_EFFORT max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth 1 RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TIME_BASED_FILTER minimum_separation 0 READER_DATA_LIFECYCLE autopurge_nowriter_samples_delay INFINITE autopurge_disposed_samples_delay implementation defined 11.1.1.4.3.3 Control topic Table 11.11 Control topic, DataReader QoS Policies QoS policy Attribute Value USER_DATA value unspecified DURABILITY kind VOLATILE DEADLINE period INFINITE LATENCY_BUDGET duration INFINITE LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind BEST_EFFORT max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth implementation defined RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TIME_BASED_FILTER minimum_separation 0 READER_DATA_LIFECYCLE autopurge_nowriter_samples_delay INFINITE autopurge_disposed_samples_delay implementation defined 11.1.1.4.4 DataWriter QoS Policies DataWriter QoS policies are defined per Element, Indication and Control topic category. 11.1.1.4.4.1 Element topic Table 11.12 Element topic, DataWriter QoS Policies QoS policy Attribute Value USER_DATA value unspecified DURABILITY kind TRANSIENT DEADLINE period INFINITE LATENCY_BUDGET duration unspecified LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind RELIABLE max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth 1 RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TRANSPORT_PRIORITY value unspecified LIFESPAN duration INFINITE OWNERSHIP_STRENGTH value 0 WRITER_DATA_LIFECYCLE autodispose_unregistered_instances FALSE 11.1.1.4.4.2 Indication topic Table 11.13 Indication topic, DataWriter QoS Policies QoS policy Attribute Value USER_DATA value unspecified DURABILITY kind VOLATILE DEADLINE period INFINITE LATENCY_BUDGET duration unspecified LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind RELIABLE max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_LAST depth 1 RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TRANSPORT_PRIORITY value unspecified LIFESPAN duration INFINITE OWNERSHIP_STRENGTH value 0 WRITER_DATA_LIFECYCLE autodispose_unregistered_instances FALSE 11.1.1.4.4.3 Control topic Table 11.14 Control topic, DataWriter QoS Policies QoS policy Attribute Value USER_DATA value unspecified DURABILITY kind VOLATILE DEADLINE period INFINITE LATENCY_BUDGET duration unspecified LIVELINESS kind AUTOMATIC lease_duration INFINITE RELIABILITY kind RELIABLE max_blocking_time unspecified DESTINATION_ORDER kind BY_SOURCE_TIMESTAMP HISTORY kind KEEP_ALL depth UNLIMITED RESOURCE_LIMITS max_samples UNLIMITED max_instances UNLIMITED max_samples_per_instance UNLIMITED TRANSPORT_PRIORITY value unspecified LIFESPAN duration INFINITE OWNERSHIP_STRENGTH value 0 WRITER_DATA_LIFECYCLE autodispose_unregistered_instances FALSE
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13043: Remove definition of QoS which are not functional relevant (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

Remove definition of QoS which are not functional relevant: Unclear why TRANSPORT_PRIORITY, RESOURCE_LIMITS are defined. These QoS policies relate to system design and are functionally irrelevant.

Issue 13044: Add motivation value QOS Destination_Order (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Add motivation value QOS Destination_Order: Motivation for DESTINATION_ORDER BY_SOURCE_TIMESTAMP is unclear. It might be related to the demand for executing different commands on the same element in time order. In that case motivate the choice. BY_SOURCE_TIMESTAMP requires aligned time awareness in order to function.

Issue 13045: Inconsistent definition keys of Control Topics (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

Inconsistent definition keys of Control Topics This section states that "Control topics" have no key. AMSM.idl however defined "Element" as key for these topics. Remove "Element" as key.

Resolution: Remove "Element" as key for control topics.
Revised Text: In pages 283 and following ones: In Section 11.1.6, find the following lines and remove the word "Element" in it: #pragma keylist AMS_CT_LoadConfiguration Element #pragma keylist AMS_CT_UnloadConfiguration Element #pragma keylist AMS_CT_ShutDownESE Element #pragma keylist AMS_CT_CreateHardwareGroup Element #pragma keylist AMS_CT_ShutDown Element #pragma keylist AMS_CT_StartUp Element #pragma keylist AMS_CT_StartUpOnHost Element #pragma keylist AMS_CT_StartUpOnSpec Element #pragma keylist AMS_CT_ActivateAsPrimary Element #pragma keylist AMS_CT_Continue Element #pragma keylist AMS_CT_Halt Element #pragma keylist AMS_CT_ForceShutDown Element #pragma keylist AMS_CT_Load Element #pragma keylist AMS_CT_Stop Element #pragma keylist AMS_CT_ClearLog Element
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13046: Define history for control topics (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Define history for control topics: As "Control topics" have no key, there will be a single place buffer. The HISTORY QoS policy for "control topics" is defined to be depth 1. This implies that only one control can be issued at the same time (in a system). Proposal would be to define a history for control topics of which the depth can be implementation specific. In that case the OWNERSHIP QoS policy is not needed either.

Issue 13047: Clarify Owner and Owner object (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Clarify Owner and Owner object: It is unclear from the specification what an "Owner" or "owner object" is, how does this relate to the PIM

Resolution: Precise the paradigm.
Revised Text: In paragraph 11.1.1.5.1 ("Element Topics Data Type), complete the 15th bullet with the following text: In the PIM, the owner classes of a class can be found by going backward on associations whose other end is constrained as "key".
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13048: Association AMS_StdHWUtilization missing in PSM (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Association AMS_StdHWUtilization missing in PSM: No association to AMS_StdHWUtilization (see fig 7.20 on page 97) is defined. In the DCPS PSM that association is also missing. The figure also defines a 0..* multiplicity while on page 103 in the table 1..1 is specified for "AMS_RTHU <<optional HSM>>".

Resolution: First, it's not AMS_StdHWUtilization (US way) but AMS_StdHWUtilisation (UK way). Second, it is an enumerate that has to be used as a parameter of the template AMS_Property. Eventually, multiplicity should indeed be 0 .. *. Thus modification of table in page 103
Revised Text: Page 103, in the 3rd row, 2nd column of the table in the paragraph 7.1.10.5 (AMS_Host Class), replace the text with 0 .. *.
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13049: Typos class and interfaces: 7.1.4.3 (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Typos class and interfaces: 7.1.4.3: "An AMS_Application is an interface" should be "An AMS_ExecutableSoftwareElement is an interface" 7.1.4.8 "An AMS_Application is an interface" should be "An AMS_SoftwareSystem is an interface" 7.1.7.16 "The AMS_SEStartDependency class" should be "The AMS_SEStartCPUDependency class" 7.1.7.18 "The AMS_SEStartDependency class" should be "The AMS_SEStartTimeDependency class"

Resolution: just do it
Revised Text: In section 7.1.4.3 ("AMS_ExecutableSoftwareElement Class"), find and replace "An AMS_Application is an interface" with "An AMS_ExecutableSoftwareElement is an interface". In section 7.1.4.8 ("AMS_SoftwareSystem Class"), find and replace "An AMS_Application is an interface" with "An AMS_SoftwareSystem is an interface". In section 7.1.7.16 ("AMS_SEStartCPUDependency Class"), find and replace "The AMS_SEStartDependency class" with "The AMS_SEStartCPUDependency class". In section 7.1.7.18 ("AMS_ SEStartTimeDependencyClass"), find and replace "The AMS_SEStartDependency class" with "The AMS_SEStartTimeDependency class".
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13050: Section 7.1..8.4 (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

Some strange definitions containing "%2B"

Resolution: remove
Revised Text: In section 7.1.8.4 ("CIM_ArchitectureCheck Class") find and remove all (2) "%2B".
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13051: Section: 7.1.8.4 (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

Enumeration misses PowerPC e500 family.

Resolution: We need to find a comprehensive way to deal with all kind of extension. This may be expressed in a discussion paper and/or in future major revisions of the standard. Anyway, since it's still possible to add a new item in the enumeration in a non-standardized way, this issue doesn't preclude implementations. Disposition: Closed, no change
Revised Text:
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Issue 13052: Section: 11.1.1.3 (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

Still information about root topics Related to Issue 11517, root topics were removed, but not all info was removed. Also page 278 section 11.1.1.5.2 last bullet ("root" elements).

Resolution: remove this iformation
Revised Text: In section 11.1.1.3, remove the third bullet. In section 11.1.1.5.2, remove the 9th and last bullet.
Actions taken:
October 31, 2008: received issue
July 23, 2009: closed issue

Discussion:

Issue 13061: Clarify inheritance of CIM classes (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Clarify inheritance of CIM classes: The PIM uses the inheritance UML symbol to show a relationship which is not really an inheritance relation (e.g. attributes are not inherited from CIM). Clarify the use of this inheritance symbol for these cases.

Resolution: Precise that the CIM package is not a full copy of CIM but a projection of a part of CIM (the useful part indeed).
Revised Text: In section 7.1.1 ("Packages"), after the table, add the following text: The PIM reuses also several classes from [CIM]. This reuse is done by defining classes that match CIM classes in a specific package called "CIM". These CIM classes are a subset of the classes defined by the CIM standard and their attributes and associations are also a subset of the attributes and associations defined in the CIM standard. Thus, when an AMSM class inherits from a CIM class, it inherits just the attributes and associations that have deemed as useful in the context of C4I systems.
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13062: Clarify inheritance of CIM classes: (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Clarify inheritance of CIM classes: The PIM uses the inheritance UML symbol to show a relationship which is not really an inheritance relation (e.g. attributes are not inherited from CIM). Clarify the use of this inheritance symbol for these cases.

Resolution: See issue 13061 for disposition
Revised Text:
Actions taken:
November 12, 2008: received issue
April 30, 2009: closed issue

Issue 13063: CORBA/IDL PSM errors (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

CORBA/IDL PSM errors "8.6 page 129-172: Many IDL errors AMS_ApplicationSpecification.idl line 170: ""AMS_SecurityCheck CLASSID"" should be ""AMS_SecurityCheck_CLASSID"" line 173: ""AMS_SecurityCheck List"" should be ""AMS_SecurityCheckList"" line 174: ""AMS_ SecurityCheck ListIterator"" should be ""AMS_SecurityCheckListIterator"" AMS_CIM.idl line 846: missing ""readonly attribute"" definition line 848: missing ""readonly attribute"" definition AMS_AMSManagement.idl line 29: ""uint16"" must be ""AMS_uint16"" line 116: field identifier ""RTHS"" is also used on line 115 AMS_ApplicationSpecification.idl line 170: ""AMS_SecurityCheck CLASSID"" must be ""AMS_SecurityCheck_CLASSID"" line 173: ""AMS_SecurityCheck List"" must be ""AMS_SecurityCheckList"" line 174: ""AMS_ SecurityCheck ListIterator"" must be ""AMS_SecurityCheckListIterator"" AMS_LogicalHardware.idl line 41: Missing "";"" at EOL line 187: field identifier ""RTHU"" is also used on line 188"

Resolution: fix it
Revised Text: In section 8.6.4 ("AMS_Application.idl"), find and replace: "AMS_SecurityCheck CLASSID" with "AMS_SecurityCheck_CLASSID", "AMS_SecurityCheck List" with "AMS_SecurityCheckList", "AMS_ SecurityCheck ListIterator" with "AMS_ SecurityCheckListIterator". In section 8.6.8 ("AMS_CIM.idl"), find and replace "CIM_ThreadList ProcessThread;" with "readonly attribute CIM_ThreadList ProcessThread"; and "CIM_ServiceList ServiceList;" with "readonly attribute CIM_ServiceList ServiceList;" In section 8.6.3 ("AMS_AMSManagement.idl"), find and replace "AMS_Util::uint16" with "AMS_Util::AMS_uint16", find and remove the line with AMS_LogicalHardware::AMS_RTHardwareUtilisation RTHS;". In section 8.6.7 ("AMS_ApplicationSpecification.idl"), find and replace "AMS_SecurityCheck CLASSID" with "AMS_SecurityCheck_CLASSID", "AMS_SecurityCheck List" with "AMS_SecurityCheckList", "AMS_ SecurityCheck ListIterator" with "AMS_SecurityCheckListIterator". In section 8.6.9 ("AMS_LogicalHardware.idl"), add a ";" after the closing bracket } of the "enum AMS_StdHWUtilisation" block; find and remove the line "readonly attribute AMS_RTHardwareUtilisation RTHU;"
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13064: XML PSM: referenced type name incorrect (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

XML PSM: referenced type name incorrect AMS_SupportedApplicationModel.xsd: AMS_SupportedMechanims_LinkType on line 160 must be AMS_SupportedMechanisms_LinkType.

Resolution: Change AMS_SupportedMechanims_LinkType with AMS_SupportedMechanisms_LinkType.
Revised Text: In Section 9.6.10 ("Supported Application Model"), find and replace "AMS_SupportedMechanims_LinkType" with "AMS_SupportedMechanisms_LinkType".
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13065: AMS_StdState not explained (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

AMS_StdState not explained The referenced class AMS_StdState class is not defined nor explained in the PIM.

Resolution: Add a section on AMS_StdState.
Revised Text: Add a section "7.1.4.9 AMS_StdState Class" with the following text: This class enumerates the standardized platform-specific state for an AMS_ExecutableSoftwareElement. ST_NONSTD denotes a non-normalized value and ST_ENV denotes the value of the environment variables. Enumeration ST_NONSTD ST_ENV Disposition: Resolved
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13066: DCPS PSM: typo in field CIM_ProcessThead (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

DCPS PSM: typo in field CIM_ProcessThead must be "CIM_ProcessThread" (2 times). This is AMSM.idl from DCPS PSM line 594 and line 607.

Resolution: agree
Revised Text: In paragraph 11.1.6, find and replace CIM_ProcessThead with CIM_ProcessThread (two times: in the "CIM_Process" block and in the "CIM_UnixProcess" block).
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13067: PIM: No alternative models possible (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

PIM: No alternative models possible No way to specify alternative model types other than PROCESS, J2EE and CCM

Resolution:
Revised Text:
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Discussion:

Even if that's true, no way to specify alternative model types other than process, J2EE and CCM, the FTF cannot change this because 1/ it's not required by the RFP, 2/ the DTC, thus, didn't vote for that, 3/ this does not prevent implementation work.  Thus, this issue has to closed and reported to the C4I DTF in order to include it in a future 2nd version of AMSM.  Disposition:	Closed, no change

Issue 13068: Not all expected ESE state changes are described (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Not all expected ESE state changes are described State changes that are initiated by the managed process are not described in the state diagram. For instance a managed process can terminate with returning a code indicating an error. There is no state change from RUNNING to ERROR however.

Resolution: Add a state change from RUNINNG to ERROR. This state change doesn't imply a new method since it's caused by the crash of the process. Specify that the state change "STOP" can be initiated by the process itself.
Revised Text: eplace Fig 7.27 ("Executable Software Element state diagram") with the following one: In the table of the paragraph 7.1.14.1.4 ("Running"): Replace the second line with the following one: STOP Stop the Software Element. This Transition is also automatically followed when the Executable Software Element normally stops. Add the following line: error This transition is automatically followed when the Executable Software Element crashes.
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13069: Inconsistent naming of compositions (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Inconsistent naming of compositions Composistions SupportedModelType and SupportedOSType should have been defined plural in order to be consistent with the other compositions. This might be an issue for the whole document.

Resolution: Add an "s" to these compositions.
Revised Text: Replace the Figure 7.25 ("Supported Application Model class diagram") with the following one: In the 5th line of the table in the section 7.1.12.8 "AMS_SupportedApplicationModel Class"), add a 's' to "SupportedModelType". In the 6th line of the table in the section 7.1.12.8 "AMS_SupportedApplicationModel Class"), add a 's' to "SupportedOSType". In section 8.6.11 ("AMS_SupportedApplicationModel.idl"), page 172, in the interface AMS_SupportedApplicationModel, replace add a 's' to "SupportedModelType" and "SupportedOSType". In section 9.6.10 ("Supported Application Model"), page 218, 3rd and 5th lines, add a 's' to "SupportedModelType" and "SupportedOSType". In section 11.1.6 ("Mapping"), page 287, in the "AMS_SupportedApplicationModel" struct, add a 's' to "SupportedModelType" and "SupportedOSType".
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13070: Undefined order (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

Undefined order The model does not define any order in execution of actions defined by the "CIM_Action" class and the "CIM_ActionSequence". This might be relevant, thus the model must express that. If it is defined in CIM, refer to the CIM document and location or copy the definition.

Resolution: Specify that actions are ordered and how their execution depends on that order.
Revised Text: Replace the figure 7.15 ("Application Specification class diagram"), page 62, with the following one: Replace the figure 7.16 ("Action Specification class diagram"), page 63, with the following one: In section 7.1.7.7 ("AMS_ESESpec Class"), page 68, add the following bullet just before the table: � An ordered list of actions (AMS_SoftwareElementAction), these actions shall be executed in this order. The first action to execute is the reference action of the AMS_ESESpec. In section 7.1.7.7 ("AMS_ESESpec Class"), page 68, replace the first cell of the 9th line with "AMS_SoftwareElementAction {ordered}". In section 7.1.7.23 ("AMS_SoftwareFeatureSpec Class"), page 72, add the following bullet just before the table: � An ordered list of actions (AMS_SoftwareElementAction), these actions shall be executed in this order. The first action to execute is the reference action of the AMS_ESESpec. In section 7.1.7.23 ("AMS_SoftwareFeatureSpec Class"), page 72, replace the first cell of the 9th line with "AMS_SoftwareFeatureAction {ordered}". In section 7.1.8.1 ("CIM_Action Class"), page 72, add just before the table the following text: A CIM_Action owns also an ordered sequence of actions ("CIM_ActionSequence"). These actions shall be executed in this order after the owning action itself. In section 7.1.8.1 ("CIM_Action Class"), page 72/73, replace the first cell of the 6th line of the table with "CIM_ActionSequence {ordered} {override}
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13071: XSD specification of AMS_SupportedApplicationModel not consistent with model (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

XSD specification of AMS_SupportedApplicationModel not consistent with model The AMS_SupportedApplicationModel class as defined in section 7.1.12 is specified to contain uncorrelated collections of AMS_ModelType, AMS_OsType, AMS_State, etc. The XSD specification defines the AMS_SupportedApplicationModel as a collection of records, where each record contains one AMS_ModelType, AMS_OsType, etc. Thus the XSD specifies an unwanted correlation between those element.

Resolution: Unleash the correlation among these items.
Revised Text: In section 9.6.10 ("Supported Application Model"), page 217 (3 last lines) and 218 (20 first lines), replace the "AMS_SupportedApplicationModelType" block with the following: <xsd:complexType name="AMS_SupportedApplicationModelType" mixed="false"> <xsd:complexContent> <xsd:extension base="CIM_LogicalElementType"> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="SupportedModelTypes" type="AMS_ModelType" /> </xsd:sequence> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="SupportedOSTypes" type="AMS_OSType" /> </xsd:sequence> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="SupportedControls" type="AMS_Control" /> </xsd:sequence> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="SupportedStates" type="AMS_State" /> </xsd:sequence> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="SupportedMechanisms" type="AMS_SupportedMechanisms_LinkType" /> </xsd:sequence> <xsd:attribute name="Name" type="xsd:string" use="required" /> <xsd:attribute name="ConfigurationInfo" type="xsd:string" use="required" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>
Actions taken:
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13072: AMS_RTSWIndication unpractical/incorrect definition (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

AMS_RTSWIndication unpractical/incorrect definition The attribute ElementCase equals the discriminant of the union Element and should be removed. As an preferred solution, the union can be replaced by just one string indicating the referenced topic, the union cases only differentiate in naming of the attribute, not the type. This allows setting a query on this field. The keylist is also incorrect, a union may not be part of the keylist. AMS_RTSW should also not be part of the keylist because an Element can have only one state at a time.

Resolution: Replace the union Element with a struct as proposed. Modify the keylist as proposed as well.
Revised Text: In section 11.1.6 ("Mapping"), in page 281 and 282, replace the following text: // union AMS_RTSWIndication_Element switch (AMS_RTSWIndication_Case) { case AMS_ESE_IndicationCase: // full name of elements of AMS_ExecutableSoftwareElement string ESE; case AMS_Application_IndicationCase: // full name of elements of AMS_Application string Application; case AMS_System_IndicationCase: // full name of elements of AMS_SoftwareSystem string System; case AMS_LB_IndicationCase: // full name of elements of AMS_LoadBalancingGroup string LB; case AMS_FT_IndicationCase: // full name of elements of AMS_RedundancyGroup string RG; }; struct AMS_RTSWIndication { // AMS_RTSWIndication_Case ElementCase; AMS_RTSWIndication_Element Element; // AMS_RTSoftwareStatus AMS_RTSW; // string IndicationTime; }; #pragma keylist AMS_RTSWIndication Element,AMS_RTSW With the following: // struct AMS_RTSWIndication { // AMS_RTSWIndication_Case ElementCase; // full name of elements of AMS_ExecutableSoftwareElement // full name of elements of AMS_Application // full name of elements of AMS_SoftwareSystem // full name of elements of AMS_LoadBalancingGroup // full name of elements of AMS_RedundancyGroup string Element; // AMS_RTSoftwareStatus AMS_RTSW; // string IndicationTime; }; #pragma keylist AMS_RTSWIndication Element
Actions taken:
November 12, 2008: received issue
November 12, 2008: received issue
July 23, 2009: closed issue

Issue 13073: AMS_SoftwareSystem Owner (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:

AMS_SoftwareSystem Owner: The Owner is defined as a bounded sequence of maximum length 1. Expressing a non existing owner can be done by means of an empty string. Thus a sequence is not needed. As an advantage, Owner can be used in a query expression.

Resolution: modify as proposed
Revised Text: In Section: 11.1.6, page 288, replace the17th line backward from the end of the page with the following line: string Owner;
Actions taken:

Issue 13221: CIM_NextHopRoute topic defined In the DCPS PSM (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

CIM_NextHopRoute topic defined In the DCPS PSM CIM_NextHopRoute is defined while the PIM defines it as an abstract class. Remove this topic.

Resolution: Remove the topic.
Revised Text: In the section 11.1.6, page 292, remove the following lines: // struct CIM_NextHopRoute { // the full name of an element of AMS_Host // the full name of an element of AMS_Router string Owner; // sequence of full names of elements of CIM_RemoteServiceAccessPoint sequence<string, 1> CIM_AssociatedNextHop; // sequence of full names of elements of CIM_ProtocolEndPoint sequence<string, 1> CIM_RouteUsesEndpoint; // string InstanceID; // string DestinationAddress; // short AdminDistance; // short RouteMetric; // boolean IsStatic; // short TypeOfRoute; }; #pragma keylist CIM_NextHopRoute InstanceID,Owner
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13226: figure 7.8 invalid (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

"optional LBM" stereotype The RedState stereotype is defined to be "optional FTM" and "optional LBM" while the targeted class is only "optional FTM". Remove the "optional LBM" stereotype.

Resolution: Remove the "optional LBM" stereotype
Revised Text: Replace the figure 7.7 ("Application Class diagram (2/3)") with the following one: In section 7.1.4.3 ("AMS_ExecutableSoftwareElement Class"), page 44, remove the "<<optional LBM>>" in the 1st cell of the 8th line.
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13227: Signed integers in DCPS PSM (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

Signed integers in DCPS PSM All unsigned numerical values from the PIM are mapped to signed numbers in the DCPS PSM

Resolution: All numerical values in the PIM are unsigned numbers, it so 'enough' to change all the numbers to unsigned equivalent.
Revised Text: n section 11.1.3 ("Specific data types"), page 280, in the table 11.5 ("Data types for DCPS PSM"), "short" with "unsigned short", "long" with "unsigned long" and "long long" with "unsigned long long". In section 11.1.6, from page 281 to 301, find and replace "short" with "unsigned short", "long" with "unsigned long" (which include all the "long long" cases).
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13229: StartUp/ShutDown DeploymentConfiguration (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

It is unclear why there is a StartUp and a Shutdown method on the AMS_DeploymentConfiguration class. It seems not logical how to manage executable software element through different views on the system

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

The capability to group the startups and stopdowns of ESE in a deployment configuration was required by the RFP.   Moreover, the submission purposely does not standardize how this is supposed to be implemented and let that to implementers' knowhow.  Disposition:	Closed, no change

Issue 13230: Control response (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

It is unclear if the control response will be used when e.g. StartUp method will be successfully executed. If it will be used than AMS_ErrorCode is missing the code AMS_OK.

Resolution: The PIM does have this value but it was not mapped in PSMs.
Revised Text: In Section 8.6.1, page 129, in the enum AMS_ErrorCode, add first place the following line: AMS_OK, In Section 11.1.6, page 282, in the enum AMS_ErrorCode, add first place the following line: AMS_OK,
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13232: Target not specified (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Missing the relationship to the target ESE spec for AMS_SEShutdownDependency, and AMS_SEStartTimeDependency

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

These relationships are association classes which are usually not describe more than that throughout the PIM (see "AMS_SoftwareFeatureAction", "AMS_SoftwareElementAction", "AMS_SoftwareFeatureCheck", "AMS_SEStartTimeDependency" and others). Thus, we won't change anything since all information needed are present (in the text of the association class or in the class of the classes that are in relation).  Disposition:	Closed, no change

Issue 13233: Error return values missing of LoadConfiguration and UnloadConfiguration (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

For AMS_ConfManagement the possible return values of the operations LoadConfiguration and UnloadConfiguration are not specified

Resolution: Add the AMS_NOK for those cases.
Revised Text: At the end of the Table 7.4 ("Error Codes"), add the following line: AMS_NOK The operation didn't work properly (see log). In section 7.1.3.2.1 ("LoadConfiguration (file: String)") and 7.1.3.2.2 ("UnloadConfiguration (file: String)"), add the following line: This operation shall return AMS_NOK if it doesn't work properly (see log for more information). In Section 8.6.1 ("AMS_Util.idl"), page 129, replace the AMS_ErrorCode enum with the following one: enum AMS_ErrorCode { AMS_OK, AMS_UNKNOWN, AMS_BADFILTER, AMS_BADSUBSCRIPTIONID, AMS_BADCONNECTIVITY, AMS_BADDEVICES, AMS_BADRESOURCES, AMS_BADMODELTYPE, AMS_BADCOMMANDLINE, AMS_BADACTION, AMS_BADCHECK, AMS_BADSTATE, AMS_HALTFAILED, AMS_STARTFAILED, AMS_SHUTDOWNFAILED, AMS_LOADFAILED, AMS_STOPFAILED, AMS_CONTFAILED, AMS_DEPLOYFAILED, AMS_PRIMARYFAILED, AMS_RESOURCEERROR, AMS_RIGHTERROR, AMS_NOTCHECKED, AMS_ALREADYPRIMARY, AMS_NOTFT, AMS_NOK }; In section 11.1.6, page 282 and 283, replace the AMS_ErrorCode enum with the following one: enum AMS_ErrorCode { AMS_OK, AMS_UNKNOWN, AMS_BADFILTER, AMS_BADSUBSCRIPTIONID, AMS_BADCONNECTIVITY, AMS_BADDEVICES, AMS_BADRESOURCES, AMS_BADMODELTYPE, AMS_BADCOMMANDLINE, AMS_BADACTION, AMS_BADCHECK, AMS_BADSTATE, AMS_HALTFAILED, AMS_STARTFAILED, AMS_SHUTDOWNFAILED, AMS_LOADFAILED, AMS_STOPFAILED, AMS_CONTFAILED, AMS_DEPLOYFAILED, AMS_PRIMARYFAILED, AMS_RESOURCEERROR, AMS_RIGHTERROR, AMS_NOTCHECKED, AMS_ALREADYPRIMARY, AMS_NOTFT, AMS_NOK };
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13234: Implications of UnloadConfiguration (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

When is it allowed to call UnloadConfiguration. Does this depends on the state of the concerned entity, for example SoftwareSystem

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

This is deemed as implementation dependent.  Disposition:	Closed, no change

Issue 13235: AMS_ESEDeployed missing (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

The association between a AMS_ExecutableSoftware Element and AMS_DeploymentLink is not drawn in figure 7.7

Resolution: This association is shown in the figure 7.12 ("Application Deployment class diagram") because it's an element of the Application Deployment package. Disposition: Closed, no change
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13236: Purpose of a link from another AMS_DeploymentSpec (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

What is the purpose of an AMS_DeploymentLinkSpec referencing an AMS_DeploymentLinkSpec from another AMS_DeploymentSpec. This implies that one AMS_ESESpec can be used to deploy several AMS_ExecutabeSoftwareElement's. How relates this to AMS_OSUsed and AMS_HostUsed.

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

This association was required by the RFP and its precise semantics is left at the assessment of the implementers.  Disposition:	Closed, no change

Issue 13238: AMS_SEStartCPUDependency is specified on the association between two AMS_ESESpecs (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

The AMS_SEStartupCPUDependency defined as an association class between AMS_ESESpec. However it only depends on the CPU load of the system and not on the other AMS_ESESpec.

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

The AMS_SEStartDependency classes are to specify the ESEs that have to be started after the given ESE. This starting may be performed either after a given delay or when a given CPU load is reached. Anyway, all AMS_SEStartDependency classes link an ESE and its following ESEs.  Disposition:	Closed, no change

Issue 13239: No extension mechanism defined for Checks (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

The Check specification does not provide an extension mechanism to define implementation specific check as does the Action specification.

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

{That's true and adding a new one is out of the scope of an FTF or an RTF. This issue will have to be dealt with in the second version.  Disposition:	Closed, no change

Issue 13240: The transitions ALLOCATE and RECLAIM are unclear (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

The actions (control) associated with the transitions ALLOCATE and RECLAIM are not specified.

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

The precise semantics behind these transitions is left to the implementers.  Disposition:	Closed, no change

Issue 13241: SoftwareElementID is not a required attribute for AMS_ESESpecType (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

The attribute SoftwareElementID of AMS_ESESpec is not specified as required. However in the PIM the SoftwareElementID is defined as a key property.

Resolution: Define this attribute as required in the XSD.
Revised Text: In section 9.6.6, page 192, find and replace the following texte <xsd:attribute name="SoftwareElementID" type="xsd:string" /> With the following text: <xsd:attribute name="SoftwareElementID" type="xsd:string" use="required"/>
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13242: RedInitState attribute of AMS_ESESpecType defined as required (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

Why is the RedInitState attribute of AMS_ESESpecType defined as required while it is optional FTM. Why not specify a default value for RedInitState

Resolution: Define this attribute as optional in the XSD
Revised Text: In section 9.6.6, page 192, find and replace the following snippet <xsd:attribute name="RedInitState" type="AMS_RedundancyEltState" use="required" /> With the following one: <xsd:attribute name="RedInitState" type="AMS_RedundancyEltState" />
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13243: TargetOperatingSystem attribute of CIM_OSVersionCheck defined as int (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

The TargetOperatingSystem attribute of CIM_OSVersionCheck has type int. It may be better to specify it as an enumeration e.g. AMS_OSType.

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

{One of the main design tenets of this submission is to reuse DMTF's CIM classes and attributes as they are. Since DMTF defined CIM_OSVersionCheck as an int, we won't change it. }  Disposition:	Closed, no change

Issue 13244: Mapping of owner attribute not explained (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

A number of XSD element definitions contain the optional attribute owner. Mostly the owner of an element is defined implicit by the enclosing element. The specification should explain the use of the owner attribute

Resolution: Precise the paradigm.
Revised Text: In paragraph 9.1.2 ("Mapping principle"), complete the last bullet with the following text: In the PIM, the owner classes of a class can be found by going backward on associations whose other end is constrained as "key".
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13245: LinkID attribute of AMS_DeploymentLinkSpecType not specified as required (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

The attribute LinkID of AMS_DeploymentLinkSpecType is not specified as required, while the PIM specifies this attribute as the key.

Resolution: Move this attribute to optional
Revised Text: In section 9.5.6, page 189, find and replace the following snippet: <xsd:attribute name="LinkID" type="xsd:string" /> With the following one: <xsd:attribute name="LinkID" type="xsd:string" use="required"/>
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13247: Inconsistent use of start and shutdown (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Revision
Severity: Significant
Summary:

In the ActionCheckCase there is a CASE_START and a CASE_SHUTDOWN. When you call one state START than the other should be named STOP. In common in this document the term startup and shutdown is used, but for ESE and application it would be logical to use start and stop.

Resolution: Replace CASE_SHUTDOWN with CASE_STOP, CASE_PRE_SHUTDOWN with CASE_PRE_STOP, CASE_POST_SHUTDWON with CASE_POST_STOP.
Revised Text: In pages 66, replace CASE_SHUTDOWN with CASE_STOP (2 times), CASE_PRE_SHUTDOWN with CASE_PRE_STOP (2 times), CASE_POST_SHUTDWON with CASE_POST_STOP (2 times). In pages 143, replace CASE_SHUTDOWN with CASE_STOP (1 time), CASE_PRE_SHUTDOWN with CASE_PRE_STOP (1 time), CASE_POST_SHUTDWON with CASE_POST_STOP (1 time). In pages 148, replace CASE_SHUTDOWN with CASE_STOP (1 time), CASE_PRE_SHUTDOWN with CASE_PRE_STOP (1 time), CASE_POST_SHUTDWON with CASE_POST_STOP (1 time). In pages 190, replace CASE_SHUTDOWN with CASE_STOP (1 time), CASE_PRE_SHUTDOWN with CASE_PRE_STOP (1 time), CASE_POST_SHUTDWON with CASE_POST_STOP (1 time). In pages 256, replace CASE_SHUTDOWN with CASE_STOP (1 time), CASE_PRE_SHUTDOWN with CASE_PRE_STOP (1 time), CASE_POST_SHUTDWON with CASE_POST_STOP (1 time). In pages 257, replace CASE_SHUTDOWN with CASE_STOP (1 time), CASE_PRE_SHUTDOWN with CASE_PRE_STOP (1 time), CASE_POST_SHUTDWON with CASE_POST_STOP (1 time).
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13248: The construction of global names of an instance is unclear. (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

The Naming Convention specifyies that it reuses the DMTF CIM naming convention which is based on so-called "weak" associations. However in the CIM specification a weak association results in the propagation of the key properties to the dependent class. In the AMSM specification this is not the case. For a association link from class A to class B the AMSM specification states that the global name of an instance B is constructed by concatenating the global name of an instance of A with the key values of B. However the AMSM specification does not specify the syntax for the construction of the global names. Further it should provide an example.

Resolution: Remove any reference to DMTF CIM in section 7.1.2.1. Add an example. Specify more clearly how the global name have to be built. State that the value of a key attribute shall be unique for all the instance of a class. Add the class name and the attribute name in the global name in order to avoid the cases where classes have a key relation with themselves and another key relation with another class. These cases lead to mistake because key names are unique per class and not for the whole model.
Revised Text: Replace the text of the section 7.1.2.1 with the following one: In order to give a normalized global name to instantiations of the classes of this model, the AMSM service uses a naming convention that is based on specific attributes and associations of the class of the considered element. In the models shown hereafter, an UML constraint ("key") have been used to mark these specific attributes and associations. As already stated, the owner classes of a class can be found by going backward on associations whose other end is constrained as "key". The global name of an instance I of a class B is thus given by the following rules: � If i has no owner, its global name is given by its only attribute marked as "{key}" with the following syntax: "<className>.<attributeName>=<Value>". The value of a key attribute shall be unique for all the instances of a given class. � Else, the global name of i is constructed by concatenating: o the global name of its owner, o the letter ":" (ASCII code 58), and o the only attribute of i marked as "{key}" with the following syntax: "<className>.<attributeName>=<Value>".. Example 1: Considering the following excerpt of the PIM and an Executable Software Element named "ESE" residing in an application named "App" which resides in a system named "System" with doesn't reside in any other system. Thus, the global name of the system is "AMS_SoftwareSystem.Name=System" (no "owner", key attribute "Name"), the global name of the application is "AMS_SoftwareSystem.Name=System:AMS_Application.Name=App" (Owner given by the key association "CIM_SystemComponent", key attribute "Name"), and the global name of the Executable Software Element is "AMS_SoftwareSystem.Name=System: AMS_Application.Name=App:AMS_ExecutableSoftwareElement=ESE" (Owner given by the key association "CIM_SystemComponent", key attribute "Name"). Example 2: In the same context, an Executable Software Element named "ESE" residing in an application named "test2" which resides in a second application name "test1" in a system named "test1" with doesn't reside in any other system. The global name of ESE is: "AMS_SoftwareSystem.Name=test1: AMS_Application.Name=test1: AMS_Application.Name=test2:AMS_ExecutableSoftwareElement=ESE".
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Issue 13249: Unclear how a software system is deployed (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

After loading the specification files the SoftwareSystem must be deployed. However the classes in the Management Package do not provide a method to access an AMS_DeploymentSpec directly. What is the way to deploy a SoftwareSystem.

Resolution:
Revised Text:
Actions taken:
January 13, 2009: received issue
July 23, 2009: closed issue

Discussion:

In this version of the spec, deployment issues are left to implementers.  Disposition:	Closed, no change

Issue 13326: Unclear what a AMS_DeploymentLinkSpec describes. (amsm-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:

Unclear what a AMS_DeploymentLinkSpec describes. In the description of the AMS_DeploymentLinkSpec class it is mentioned that a software item (application, software system, or software element) will have to run on some hosts. However an AMS_DeploymentLinkSpec has only an association with an AMS_ESESpec and thus with a software element and not with an application or software system. Explain how an AMS_DeploymentLinkSpec is related to an application or software system.

Resolution: Applications and software system are not deployed on one host but on a network. Clarify this in the description of the AMS_DeploymentLinkSpec class.
Revised Text: Replace the first paragraph of the section 7.1.6.2 on page 59, with the following one: The AMS_DeploymentLinkSpec class models the fact that a software executable element will have to run on some hosts. These hosts are defined either as an actual host or with a kind of host (requested hardware).
Actions taken:
January 23, 2009: received issue
July 23, 2009: closed issue

Issue 13508: paragraph numbering (amsm-ftf)

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

Paragraphs 7.1.3 to 7.1.14 should be 1 level higher (7.2 to 7.13) Paragraphs 10.1.1 to 10.1.4 should be 1 level higher (10.2 to 10.5) Create a paragraph 11.1.2 �Mapping principle� with paragraphs 11.1.1.1 to 11.1.1.5.4 in it. Paragraphs 11.1.2 to 11.1.6 should be 1 level higher (11.2 to 11.6) Paragraph 12.5.1 should be 12.6

Resolution: agree
Revised Text: Move paragraphs 7.1.3 to 7.1.14 by 1 level higher (7.2 to 7.13) Move paragraphs 10.1.1 to 10.1.4 by 1 level higher (10.2 to 10.5) Create a paragraph 11.1.2 "Mapping principle" with paragraphs 11.1.1.1 to 11.1.1.5.4 in it. Move paragraphs 11.1.2 to 11.1.6 by 1 level higher (11.2 to 11.6) Move paragraph 12.5.1 to 12.6.
Actions taken:
February 18, 2009: received issue
July 23, 2009: closed issue