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

No Data Available

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

Add the AMS_NOK for those cases.

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

Precise the paradigm.

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

No Data Available

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.

No Data Available

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

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

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

No Data Available

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

No Data Available

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

Define this attribute as optional in the XSD

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.

The PIM does have this value but it was not mapped in PSMs.

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

Define this attribute as required in the XSD.

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.

No Data Available

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

No Data Available

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"

fix it

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.

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.

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.

Applications and software system are not deployed on one host but on a network. Clarify this in the description of the AMS_DeploymentLinkSpec class.

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.

No Data Available

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.

Replace CASE_SHUTDOWN with CASE_STOP, CASE_PRE_SHUTDOWN with CASE_PRE_STOP, CASE_POST_SHUTDWON with CASE_POST_STOP.

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

agree

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

Move this attribute to optional

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.

Unleash the correlation among these items.

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.

Specify that actions are ordered and how their execution depends on that order.

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.

Replace the union Element with a struct as proposed. Modify the keylist as proposed as well.

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

Remove the topic.

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.

modify as proposed

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.

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.

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

No Data Available

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

No Data Available

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

All numerical values in the PIM are unsigned numbers, it so 'enough' to change all the numbers to unsigned equivalent.

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.

agree

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

Add a section on AMS_StdState.

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.

Add an "s" to these compositions.

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

Remove the "optional LBM" stereotype

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

Change AMS_SupportedMechanims_LinkType with AMS_SupportedMechanisms_LinkType.

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

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

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

The description of the transition CONTINUE is to be added and the description of the transition STOP_HALTED must be fixed.

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.

Move the HALTED state from the Normal Package to the Maximum Control Package as long as the matching functions and transitions

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

; 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

All these issues are syntactic errors.

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.

Reshape the section about QoS for the DCPS mapping.

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.

Reshape the section about QoS for the DCPS mapping.

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.

Reshape the section about QoS for the DCPS mapping.

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.

Separate the CurrentState attribute for the sake of the ease of implementability.

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.

Reshape the section about QoS for the DCPS mapping.

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.

Remove "Element" as key for control topics.

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

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

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

Precise the paradigm.

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.

See issue 13061 for disposition

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.

Precise that the CIM package is not a full copy of CIM but a projection of a part of CIM (the useful part indeed).

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

remove this iformation

Enumeration misses PowerPC e500 family.

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

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"

just do it

Some strange definitions containing "%2B"

remove