Issues for Mailing list of the PIM & PSM For Software Radio Finalization Task Force

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

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

Issue 7578: A provided port can have multiple interfaces
Issue 7579: Obtaining resource provided interfaces during deployment
Issue 7580: DisconnectPort operation
Issue 7581: file Service becomes part of the CF name space.
Issue 7582: Lack of XML definition
Issue 7583: Physical layer TBD needs to be fixed in the annex
Issue 7584: Specify which interfaces are mandatory
Issue 7585: Break the spec into multiple volumes
Issue 7586: Lack of OCL Statements for constraints
Issue 7587: Replace expanded/duplicated IDL in CORBA modules with include statements
Issue 7588: Start/stop behavior
Issue 7596: Keep text constraint descriptions in addition to OCL as OCL is hard to read
Issue 7655: swradio issue primitive types
Issue 7656: Typos and Acrynoms definitions missing in in section 9.5
Issue 7657: Section 9.2.4.2 IStatusSignal
Issue 7658: Facilities Parameter Modes and Type definitions
Issue 7660: Port related interfaces
Issue 7661: Lack Consistent use of SWRadio Stereotypes in Facilities interface
Issue 7662: Add Properties CORBA PSM Definition
Issue 7672: inconsistent wording in ResourceComponents
Issue 7684: Lack Consistent use of SWRadio Stereotypes in Facilities interface
Issue 7688: Add definition for Properties
Issue 7689: Name problem
Issue 7690: Name problem section 8.1.2.6
Issue 7691: Name problem Section 8.1.2.7, pg 51
Issue 7692: Model and description does not agree
Issue 7693: Missing stereotype
Issue 7694: Explanation of different port types
Issue 7695: Missing explanation for invalid properties
Issue 7696: Missing reference to the figure
Issue 7697: Issue: Wrong name
Issue 7698: Cardinality problem
Issue 7699: redundant Association Section 8.1.6.4, pg 88.
Issue 7700: redundant Association Section 8.1.6.5, pg 89
Issue 7701: redundant Association Section 8.1.6.6, pg 90
Issue 7702: redundant Association Section 8.1.6.7, pg 91
Issue 7703: Missing stereotype descriptions
Issue 7704: Missing constraint Section 8.2.6, pg 103
Issue 7705: Missing attributes Section 8.2.6.3, pg 106
Issue 7706: Name change Section 8.2.6.4, pg 107
Issue 7707: Name change Section 8.2.6.4.2, pg 110
Issue 7708: Redundant class name Section 8.2.6.4.3, pg 110
Issue 7709: Name change Section 8.2.6.4.4, pg 111
Issue 7710: Name change Section 8.2.6.4.5, pg 111
Issue 7711: Name change Section 8.2.6.4.7, pg 113
Issue 7712: Name change Section 8.2.6.4.8, pg 114
Issue 7713: Wrong section name
Issue 7714: Invalid reference
Issue 7715: Description Section 8.3.2.4, pg 128
Issue 7716: I/O_Algorithm description
Issue 7717: LogicalSecurityChannel
Issue 7718: wrong reference throughout Section 8.3.3.1
Issue 7719: wrong semantics description
Issue 7720: Irrelevant description
Issue 7725: 9.3.1.1.1 ILocalLinkManagement
Issue 7726: 9.3.1.2.1 ConnectionlessLink Component
Issue 7727: 9.3.1.3.1 IAckConnectionless
Issue 7728: AckReplyPdu definition
Issue 7729: 9.3.1.1.1 ILocalLinkManagement
Issue 7742: M1 and M2 data for the UML Profile for SWRadio
Issue 7781: Correct the typos in the spec
Issue 7785: "WaveForm" and "Application" are not used consistantly
Issue 7786: ApplicationFactory
Issue 7787: Section 9.3.1.4.1, IConnectionLink Operations
Issue 7789: Section 9.2.5.3 IPdu specialization
Issue 7845: PIM-PSM translation
Issue 7849: Remove any reference to IScheduling from the specification
Issue 7853: Section 9.2.6.1 IStream localSetup operation
Issue 7868: Lacking component definitions in IO Facilities Section (9.4
Issue 7869: Unable to import the UML Profile for SWRadio into another UML tool
Issue 7878: PSM Names Not Unique
Issue 7888: Unable able to express the direction of a port for a SWRadioComponent
Issue 7894: A port may have characteristics
Issue 7895: Primitive Type Cleanup
Issue 7898: Stereotype Display Format
Issue 7904: ControllableController ambiguity
Issue 7905: Factor out portExists() operation out of DomainManager and Devicemanager
Issue 7953: multiple interfaces on a port
Issue 7959: Figure 9-78 - Radio Set Facilities Overview
Issue 7983: Property clean up
Issue 7984: TestProperty
Issue 7985: Configure & Query Property
Issue 8121: 8.3.2, section Description
Issue 8122: 8.3.2.6, section Associations
Issue 8123: From 8.3.2.6, section Associations
Issue 8124: From 8.3.2.2, section Constrains
Issue 8125: From 8.3.2.1, section Attributes
Issue 8200: Property Enumeration
Issue 8201: Common Radio Facilities
Issue 8205: Audio I/O Facilities Attribute Types
Issue 8251: Compliance Clarification
Issue 8259: Waveform Compliance Criteria
Issue 8291: PIM and PSM for SWradio Components
Issue 8296: PSM out of sync with Facilities, 7725, 7787, and 7789 didn't update IDL
Issue 8344: remove and replace obsolete DigitalConverter references
Issue 8519: Undefined Types
Issue 8697: SWRadio UML Model is not referenced in the spec
Issue 8830: PIM and PSM for Software Radio Annex H issue 1
Issue 8831: PIM and PSM for Software Radio Annex H issue 2
Issue 8832: PIM and PSM for Software Radio Annex H issue 3
Issue 8833: PIM and PSM for Software Radio Annex H issue 4
Issue 8834: PIM and PSM for Software Radio Annex H issue 5
Issue 8835: PIM and PSM for Software Radio Annex H issue 6
Issue 8836: PIM and PSM for Software Radio Annex H issue 7
Issue 8837: DomainManager::uninstallApplication should not require removal of files
Issue 8838: PIM and PSM for Software Radio Annex H issue 8
Issue 8839: DM Install and Register Duplication Clarification
Issue 8840: registerDeviceManager description conflict
Issue 8841: reword part of create behavior
Issue 8842: Clarify purpose of composite device
Issue 8857: Issue 1. Continuation of Issue 7786
Issue 8858: Issue 2. Continuation of Issue 7786
Issue 8868: Lack of descriptor PSM definition
Issue 8869: Time type definition more than once in spec
Issue 8870: Use of Float and Double types for CommEquip and PhysicalLayer Facilities
Issue 8871: There are still some types not defined in the spec
Issue 8872: Issue: 8.1.2 Literal Specifications
Issue 8873: Correction of Invalid References to Non-Existent Property Type
Issue 8931: Application releaseObject Disconnect Behavior
Issue 8934: Section: Appendix H
Issue 8943: Inconsistent Models between Fig. 9-57 and Fig. 9-60
Issue 8948: Section 8.1.6.1.2 ExecutableDevice, Semantics
Issue 8949: ProcessIDType
Issue 8950: Service Typos in the Specification, UML Model, PSM, and IDL
Issue 8980: CFCommonTypes.idl is missing definition of TimeType
Issue 8981: IDL Scoping Rules

Issue 7578: A provided port can have multiple interfaces (swradio-ftf)

Issue 1. Unable to retrieve a specific provided interface for a port
(PortSupplier getPort operation)
Proposed Solution: Add additional parameter to the getPort operation to
qualify which provided interface object reference is needed from the
getPort operation.
Rationale: A provided port can have multiple interfaces

Resolution:
As part of the resolution to issue 7953, a constraint has been added that states each port has a set of 1 required and 1 provided interface at most.  This invalidates issue 7578.  Hence, issue 7578 should be closed with no change required to the specification based on the resolution for issue 7953.
Revised Text:
N/A
Disposition:	Closed, no change

 Obtaining resource provided interfaces during deployment. Does it
make sense to retrieve a set of provided interfaces from a resource?
Proposed Solution: Modify getPort operation to return a list back or add a
new operation.
Rationale: Efficiency could be achieved by returning all the provided or
the requested interfaces from a resource thus eliminating multiple calls to
a resource.

 DisconnectPort operation does not indicate, which required port
the disconnection is for.
Proposed Solution: add requiredPort name parameter to disconnectPort
operation.
Rationale: This is necessary unless connection id is unique at the resource
level not at the required port level.Connection ID and required port name
are parameters for the connectPort operations.

 Circular Dependency between CF and File Services IDL Name space.
This got introduced from the errata.
Proposed Solution: file Service becomes part of the CF name space.

 Comm channel data descriptors need to be defined in the annex
(currently TBD)
Rationale: Lack of XML definition

Discussion:
·	Jerry will take care of them after he is done with the OCL issues. 
·	Now that the properties resolution is in place, it will be easier to handle this issue
·	Tansu will provide a resolution for issue 7703 adding sections Databus, Interconnect etc. This needs to be done before the XML elements. 

Disposition:	Deferred
1.	Remove CharacteristicProperty from Communication Equipment. Use the definitions that are in the Properties section 8.1.3. 
2.	Make Channel an extension of Class, not a specialization
3.	Make Channel attributes CharacteristicProperty types.
4.	The Properties XML is modified to make the locallyManaged and capabilityModel elements optional so they can be used by CommEquipment definition.
5.	Update the rose model based upon changes below.

Physical layer TBD needs to be fixed in the annex
Rationale: Lack of XML definition

Discussion:
·	Jerry will take care of them after he is done with the OCL issues. 
·	Now that the properties resolution is in place, it will be easier to handle this issue
·	Tansu will provide a resolution for issue 7703 adding sections Databus, Interconnect etc. This needs to be done before the XML elements. 
Disposition:	Deferred Resolution:
1.	Update Annex F with I/O XML properties and removed RF/IF section.
2.	A follow up issue will have to be done for the RF/IF XML properties
3.	The XML files are dependent on the properties xsd file updated in Issue 7582.

Specify which interfaces are mandatory, and which ports are
required for components
Rationale: Consistency and standardization of components, improves waveform
portability of code and XML descriptors.

Discussion:
October 7, 2004 FTF Telecon:
Jerry's suggestion for how to tackle the solution for this issue:  Treat it as a base component definition.  E.g. for an audio component, at a minimum, it should have these types of features.  If audio or serial should have a required control or data port, we should specify that in the constraint section
Tansu Demirbilek provided the resolution included below, and this issue was included in the 1st ballot. However, there was some discussion on the scope of the provided resolution and the issue was pulled from the 1st ballot. 
March 10, 2005 Telecon:
Jerry:  Not sure if there is any more to be done here.  Perhaps Tansu's already submitted resolution is fine.  Tansu will touch base with Jerry during 2nd FTF.
Revised Text:
In Section 9.3.1.2.1, (ConnectionlessLink Component), pg 211, replace the following sentence in the Constraints section: 
 "ConnectionlessLinkComponent shall provide at least one bi-directional DataControl port."
with "ConnectionlessLinkComponent shall provide one ControlPort, at least one input DataControl port and at least one output DataControl port." 

In Section 9.3.1.3.1, (AckConnectionlessLink Component), pg 214, replace the following sentence in the Constraints section: 
 "AckConnectionlessLinkComponent shall provide at least one bi-directional DataControl port."
with "AckConnectionlessLinkComponent shall provide one ControlPort, at least one input DataControl port and at least one output DataControl port."
 
In Section 9.3.1.4.2, (ConnectionLinkComponent), pg 220, replace the following sentence in the Constraints section: 
 "ConnectionLinkComponent shall provide at least one bi-directional DataControl port."
with "ConnectionLinkComponent shall provide one ControlPort and at least one StreamPort."  

In Section 9.3.2.3, (MediumAccessController Component), pg 226, replace the following sentence in the Constraints section:  
 "The MediumAccessController Component shall provide at least one DataControl port."
with "MediumAccessController component shall provide one ControlPort, at least one input DataControl port and at least one output DataControl port."
 
In Section 9.5.2.1.1, (ModemComponent), pg 236, create a Constrains section and add this statement: 
 "ModemComponent shall provide one ControlPort and at least one DataControlPort or DataPort. All of the device definitions shown in Figure 9-74 that specialize ModemComponent shall provide these ports at a minimum."
  
In Section 9.5.2.2.1, (ModemComponent), pg 242, create a Constrains section and add this statement: 
 "RFIFComponent shall provide one ControlPort and at least one DataControlPort or DataPort. All of the device definitions shown in Figure 9-77 that specialize RFIFComponent shall provide these ports at a minimum."

Disposition:	Deferred                                                                                                                          
Discussion:
Not sure if there is any more to be done here.  Perhaps Tansu's already submitted resolution is fine.  Tansu will touch base with Jerry during 2nd FTF.
2nd FTF will include the changes included with this issue and the disposition. 

Disposition:	Deferred   Discussion:
No longer an issue.  What is imporptant are the interfaces, and the components are there for references.  We are only interested in platform service components being standardized and not the WFs. This issue has been overcome by events, In the Data Link Layer Facilities volume spec, DLL component definitions have constraints for the types of ports that needs to be supported.

Break the spec into multiple volumes
Proposed solution: UML Profile for SWRadio and Facilities into a separate
document of the specification
Rationale: Easier to understand, separation of concepts

Discussion:
The group (Jerry, Neli, Tansu) that the resolution for this issue (breaking up the spec into multiple volumes) does belong to this FTF.  The group agreed to 3 volumes:   PIM (UML Profile), Radio Facilities, and PSM
The group also agreed to wait until after the resolution to issue 7742 to take care of this break up.
Based on resolution for 8251 and 8259, we'll decide how to break up the spec.
Disposition:	Deferred
The issue is deferred to the follow-on R/FTF, since FTF #2 ran out of time.

Lack of OCL Statements for constraints.
Proposed Solution: Replace text constraint descriptions with OCL.
Rationale: formal language for expressing constraints and recommended
mechanism within OMG.

Discussion:
The FTF would like to get comments from the AB about the amount of OCL currently in the spec. This issue is related to issue 7742. The 2nd FTF will continue the progress based on the comments from the AB.
Disposition:	Deferred

Proposed Solution: For all CORBA Modules (e.g., CF, PortTypes,
StandardEvents, FileServices, etc.) replace IDL in the these files with
include statements.
Rationale: Definitions are based upon existing files and not duplicated,
which can lead to inconsistencies in IDL files.

What is the association or behavior in
regards to resource operations and provides and uses ports?
Proposed Solution: Association is for the uses and provides ports and no
effect on resource operations.
Rationale: Consistent behavior of resource components.

Keep text constraint descriptions in addition to OCL as OCL is hard to read

Discussion:
This is not an issue but a submitted comment on issue #7586.  It was added as an issue by mistake by the OMG. Neli has asked OMG to remove it from the issues list.
Revised Text:
N/A
Disposition:	Closed, no change

Simple primitive types are used in the specification but not
defined. Examples are the types used in Physical Layer Facilities types
(9.5) and the SimpleProperty (8.1.2.11) (e.g., double, single,  and float,
etc. ).


Recommendation:
In section 8.1.1 Base Types, section 8.1.1.7 PropertyValue add a Types
section that captures the primitive data types for boolean, char, double,
float, short, long, objtref, octet, string,
ulong, ushort and sequence of these types that are not defined UML. Octet
and OctetSequence are already defined in section 8.1.1

PIM and PSM Software Radio Components Specification


Issue: Typos and Acrynoms definitions missing in in section 9.5 Physical
Layer Facilities.
Recommendation: In Section 9.5.2, replace "centre" with "center" and
replace "pulse chapping" with "pulse shaping"
Acrynoms first usage in section 9.5 and its subsections should be first
spelled out. Add Acronyms to the acrynom list in specification.
In section 9.5.2.1.7, IPNSequenceGenerator, the figure needs subscripting

PIM and PSM Software Radio Spec Issue


Issue - Section 9.2.4.2 IStatusSignal, signalStatus operation is missing
parameter that goes with generic template StatusType.
Recommedation: Change "<<oneway>>signalStatus( )" to
"<<oneway>>signalStatus( in status : StatusType)"
Rationale: This makes the PIM agree with PSM IDL.

PIM and PSM Software Radio Components Spec Issue


Issue: Section 9.3.1.1 Local Link Management Package, Parameter modes are
missing for operation parameters. The Types definition are missing. Only
their descriptions are given. This issue is broader than this section.
These issues occur in other sections in section 9.


Recommendation: Is to add "in, out, in out, and return parameter modes."
For types define all of them. For Example,


<<enumeration>> PromisciousModeType(
                  PHYSICAL,
                  SAP,
                  MULTI)


ConnectionIDType (
                   sourceAddress: AddressType,
                   destinationAddress: AddressType,
                  priority: integer,
                  sapAddress: SAPAddressType,
                   linkService: LinkServiceType)



Rationale: To be consistent throughout the specification and to be able to
generate a PSM.

I have been reviewing the Port related interfaces in the SWRadio spec following the discussion at the FTF meeting this morning around issues 7578 and 7579. 

In doing so, I worked through a scenario which I believe is valid but not supported by the current SWRadio model (it is also broken in SCA 2.2 which is where I first ran into it). Perhaps we could discuss this in tomorrow mornings session to determine if the spec is deficient (or else my understanding of it is). If so then a new issue may be needed. Here is a synopsis:

Issue 7578 notes that a "provided port can have multiple interfaces" and proposes the addition of a parameter to the PortSupplier::getPort (possibly to be renamed as suggested this morning) operation to select the required interface. Agreed, however I believe it is also possible that a Resource (particularly a DeviceComponent) may need to expose multiple instances of a particular provides Port and need a way to distinguish between these also.

Let me try to explain what I mean using a concrete example: 

Consider an ExecutableDeviceComponent which represents a physical processor containing a set of hardware resources (watchdog timers perhaps) managed as a capacity, and which provides a Port interface to access each of these hardware resources. An Application may deploy Components on the ExecutableDevice (by specifying capacity allocations for one or more of the hardware resources) and connect them to it the provides Port on the Device (by means of devicethatloadedthiscomponentref). The Application may intend to connect each Component to the same Port instance (i.e. to the same hardware resource) or it may want to connect each to a different instance, or some combination of the two. Moreover, it is possible that another Application may be deployed and need be to connect to a unique Device Port instance(s). The Device however, has no way of distinguishing between multiple calls to the getPort operation requesting the same instance of the Port, and multiple calls requesting different instances of the Port.

(Note that on the Uses Port side, the PortConnector::connectPort/disconnectPort does not seem to suffer from the same problem since the connectionID parameter may be used to identify a particular instance).

I could not find a way to support this scenario using the current spec. I tried using a Device per hardware resource but these need to be somehow tied to the parent ExecutableDevice. I also tried saying that this is an application level problem but I don't believe the application can solve the this entirely by itself.

A possible solution: 
Add an instanceID parameter to the getPort operation (this would need to be a combination of an Application unique ID and a port instance ID).

Related problems: 
1. How does an applications profile (SAD) indicate: "multiple connections to the same Port instance, multiple connections to unique Port instances, or some combination of the two."

2. The above solution implies a need to "un-get" a Port (so that it may be reused). Is another operation required? Or perhaps there needs to be a way to (optionally) tie a Port to a capacity allocation/deallocation.

Discussion:
This is not an issue and was never submitted as a new issue to issues@omg.org.  It was simply a discussion e-mail on issues 7578 and 7579 that OMG by mistake picked up as a new issue from the SWRADIO FTF e-mail communiqué from the August 2004, Montreal Technical Meeting.  As such, it should be closed.

Revised Text:
N/A
Disposition:	Closed, no change

PIM and PSM for Software Radio Spec


Issue: Lack Consistent use of SWRadio Stereotypes in Facilities interface
Problem: The specification lacks consistent use of the SWRadio stereotypes
for the interface definitions in the Facilities. Section 8.1.3 defines the
stereotypes for ports and interfaces that are to be used for the definition
of the facilities or components in the section 9.
Recommended Solution: Replace <<interface>> stereotype with the correct
corresponding interface stereotype as described in section 8.1.3. Also the
interface names that start with "I" in the name should be removed to
consistent too. The interface stereotypes have the "I" in their names.
Rationale: Consistency

Problem: The spec only defines the XML PSM for the Property Types as
specified in section 8.1.2 Properties
Recommended Solution: Add the Properties CORBA PSM to the Annex I as I.1.2.
Move I.1 to I.1.1. I.1 name should be Properties PSMs. Update Section 10
PSM item 3 to include CORBA PSM that should probably follow the same
transformation rules as stated for the Properties XML. Recommended
placement of Properties CORBA PSM within the SWRadio CORBA module as
another module.
Rationale: Allows solutions based upon the CORBA encoding scheme instead of
XML.

Discussion:
Recommended Solution: Add the Properties CORBA PSM to the Annex I as I.1.2. Move I.1 to I.1.1. I.1 name should be Properties PSMs. Update Section 10 PSM item 3 to include CORBA PSM that should probably follow the same transformation rules as stated for the Properties XML. Recommended placement of Properties CORBA PSM within the SWRadio CORBA module as another module.
Rationale: Allows solutions based upon the CORBA encoding scheme instead of XML.

March 10, 2005 FTF Telecon:
This is a non-critical issue, as the resolution calls for just another transformation other than XML, therefore, it is not mandatory to resolve this issue within the FTF's timeframe.  Can be handled in FTF 2 only if time allows.

Disposition:	Deferred     Discussion:
This is not an error. There is no one requesting this definition. This can be handled as a RPC if someone wants to define a CORBA PSM properties definition. Jerry agrees to withdraw the issue.

Problem: In section 8.1.4, pg 58, the description says: "The SWRAPI stereotype denotes SWRadio interfaces that are used by or realized by SWRadio component. The SWRAPI interfaces are defined in the PIM facilities of this specification."

Solution: The SWRadioComponent only inherits from ComponentIdentifier and it does not realize the interfaces Resource stereotype does. Therefore, there is no PortSupplier, PortConnector etc. The sentence should read: "The SWRAPI stereotype denotes SWRadio interfaces that are used by or realized by ResourceComponent. The SWRAPI interfaces are defined in the PIM facilities of this specification."

We decided to raise an issue about the lacking consistent usage of SWRadio stereotypes throughout swrapi interfaces in chapter 9. As a result of this change, the PIM-PSM translation section (chapter 10) also needs to be changed, to reflect the mapping from <<icontrol>>, <<idata>>, etc. instead of <<swrapi>>

Discussion:
This was a comment on issue 7661 that was picked up from the SWRADIO FTF e-mail communiqué and submitted as an issue by mistake by the OMG.  As such, it should be closed. 

Revised Text:
N/A
Disposition:	Closed, no change

In Section 8.1.2, the definition of what a "property" is is missing. Add explanation

Section 8.1.2.5, pg 50. Name in the title and description does not agree. "ConfigQueryProperty" or "ConfigureQueryProperty"? 

Section 8.1.2.6, pg 51.  Name in the title and description does not agree. "ConfigQuerySimpleProperty" or "ConfigureQuerySimpleProperty"? 

Section 8.1.2.7, pg 51. Name in the title and description does not agree. "ConfigQuerySimpleSeqProperty" or "ConfigureQuerySimpleSeqProperty"? 

Section 8.1.2.10, pg 53. Description says ServiceProperty is abstract, but it's not shown as abstract in the figure.

Discussion:
Rational Rose shows the abstract stereotype definitions with italic characters, and this is the case for the ServiceProperty as shown in Fig 8-9.

Revised Text:
N/A
Disposition:	Closed, no change

Section 8.1.3, pg 57. IStreamControl stereotype is missing. We thought that in a data stream control information may be irrelevant, but there are examples of pasing header information in a data stream.

Section 8, pg 39. In the lead-in to the UML Profile, mention that the UML profile defines two different types of ports. First, in section 8.1.3, port stereotypes are defined, and these are used for stereotyping ports used and provided by SWRadio components. Second, in section 8.2.5, hardware abstraction of physical ports (analog and digital) is provided. The UML Profile definition should mention the difference between those two port definitions. Better yet, one can be renamed to avoid confusion

Section 8.1.4.6, pg 64. Under Partial Configuration exception, The last sentence reads: "The invalidPropoerties attribute returned indicate the properties that were invalid." I'd argue that the properties do not need to be invalid for partial configuration to occur. The parameter that is passed may be query parameter, or the system may not allow the change at the time of the request. 

Section 8.1.4.8, pg 65. Add reference to figure 8-10

Section 8.1.5.3, pg 77. Under associations, mainProcess: MainProcess should be changed as mainProcess: ExecutableCode

Section 8.1.6.3, pg 87. Change the cardinalities in the figure and associations from 1..* to 0..*. Change +layerA to +ServiceAccessPoint, and +layerB to +ServiceProvisionPoint. Explain those rolenames, and their possible implementation (by ports) in the semantics section. Add constraint that +SAP/+SPP association needs to be between components within the same radioSet. Also, add constraint to +radioSetA and +radioSetB association that it needs to occur between same type of waveform layer components between different radiosets. 

Section 8.1.6.4, pg 88. Remove +radioSetA, +radioSetB association, since the parent already has that

Section 8.1.6.5, pg 89. Remove +radioSetA, +radioSetB association, since the parent already has that

Section 8.1.6.6, pg 90. Remove +radioSetA, +radioSetB association, since the parent already has that

Section 8.1.6.7, pg 91. Remove +radioSetA, +radioSetB association, since the parent already has that

Stereotypes needed for Interconnect, Backplane, and Databus, under CommunicationEquipment

Discussion:
Stereotypes under CommunicationEquipment already exist that cover the need for Interconnect, Backplane, and Databus stereotypes. Specifically, the CommunicationEquipment module defines the CommunicationEquipmentConnector, IODevice, and Switch stereotypes

Section 8.2.6, pg 103. Need to add constraint that a CommEquipment shall have at least one of the following: AnalogInputPort, AnalogOutputPort, DigitalPort. 
 

Section 8.2.6.3, pg 106. Need to add the processor architecture and the capacity information

Discussion:
These attributes already exist:  processorArchitecture, nonVolatileMemoryCapaciy, volatileMemoryCapacity. 
Revised Text:
N/A
Disposition:	Closed, no change

 Section 8.2.6.4, pg 107. The IODevice really refers to an IODevice that is used for analog IO. Propose name change to avoid confusion. One can have different IO devices such as OpticalIODevice, DigitalIODevice.
 

Section 8.2.6.4.2, pg 110. Change Amplifier to AnalogAmplifier. Same ratioanale as the previous one.

 Sectoin 8.2.6.4.3, pg 110. Name DigitalConverter is used for both Digital/Analog Conterters (DAC) and Analog/Digital Converters (ADC), which is redundant. Propose removing DigitalConverter and adding two new definitions for ADC and DAC. Same ratioanale as the previous one. 

Section 8.2.6.4.4, pg 111. Change name Filter to AnalogFilter. Also reword the first sentence in the description. Same ratioanale as the previous one

Section 8.2.6.4.5, pg 111. Change name FrequencyConverter to AnalogFrequencyConverter. Same ratioanale as the previous one.

Section 8.2.6.4.7, pg 113. The description says that the radiating element can be used for translating electrical energy to electromagnetic energy or vice versa. For the electromagnetic to electrical energy conversion, there is no radiation involved for the conversion element. Propose name change as AntennaElement. 

Section 8.2.6.4.8, pg 114. Change name Switch to AnalogSwitch. Same ratioanale as the previous one

Section 8.3.1.5, pg 121. Change "Types and Exceptions" to "Attributes

Section 8.3.1.6, pg 124. There's a reference to table 8-8 in the description. Should that be the service definitions under the types and exceptions part in the same section

Section 8.3.2.4, pg 128. The description says: "For convenience, A/D and D/A conversion devices, if used, are included here" In the previous section though, the ADC and DAC's (under the name DigitalConverter) were derived from IODevice. It seems more appropriate to include ADC and DAC elements under LogicalIOChannel with the same reasoning.

Resolution:
Reject, since the assumptions used for raising this issue were wrong.  John Hogg will be raising another issue (8344) that captures the correct corrections that need to be made.  It's not an inheritance issue.
Revised Text:
N/A
Disposition:	Closed, no change

Section 8.3.2.6, pg 130. The IO channel includes an I/O_Algorithm class that does not seem to be defined any place else in the spec. Furthermore, the IO algorithm contains CODEC_Type and dataConversionType attributes which makes me think that it does physical layer processing. Does not seem appropriate. I propose removing the IO_algorithm class completely. 

section 8.3.2.7, pg 131. The LogicalSecurityChannel includes SecurityAlgortihm and SecurityKey classes that are not defined in the spec

throughout Section 8.3.3.1, subsections reference Figure 8-38 that does not show the related classes. They should be referencing 8-39 instead

Resolution:
Reject, since the described issue is incorrect. The referenced sentence above is correct.
Revised Text:
N/A
Disposition:	Closed, no change

 In section 8.3.3.1.5, pg 141. 2nd sentence of the Semantics says: "As shown in Figure 8-38 above, the DomainManager could realize up to three interfaces." However, according to figure 8-39, the DomainManager only realizes two interfaces (PropertySet and PortSupplier) and inherits from the SWRadioComponent stereotype class

In section 8.3.3.2, pg 142. 2nd sentence of the sentence is "The RadioManager extends the DomainManager by providing commu-
nication channel management within the RadioSet." This description is irrelevant from what this section describes, the RadioSystemManager. 

The unbind operations have a input bindRequest parameter and return a
BindResponseType.  This appears to be incorrect, not appropriate for unbind
behavior.


Recommendation: Remove the input bindRequest parameter and return a
BindResponseType from unbind operations. Update Figure 9-62
ILocalLinkManagement Definition. Update unbind operations definition in
operations section of 9.3.1.1.1 ILocalLinkManagement and Figure 9-62
ILocalLinkManagement Definition as follows :


unbindStream(in connectionID : ConnectionIDType)
The unbindStream operation requests the logical link provider to unbind all
SAP(s) from a stream. This operation also unbinds all the subsequently
bound SAPs that have not been unbound.


unbindSubsequentStream(in connectionID : ConnectionIDType)
The unbindSubsequentStream requests the logical link provider to unbind the
sub-
sequently bound SAP.

The ConnectionlessLinkComponent realizes IFlowControlManagement interface.
This interface is already realized by the PDU interfaces realized by
ConnectionlessLinkComponent. The component should be realizing I
FlowControlSignaling interface from Flow Control Facilities.


Recommendation
Update Figure 9-63 ConnectionlessLink Component Definition by replacing
IFlowControlManagement with IFlowControlSignaling interface from Flow
Control Facilities.


Replace corresponding text "This component realizes the
IQualityOfServiceConnectionless in-
terface for quality of service related facilities, IFlowControlManagement
for flow control interfaces, and IIndicator and IRequestPdu interfaces for
PDU based communication." in section 9.3.1.2.1 ConnectionlessLink Component
with "This component realizes the IQualityOfServiceConnectionless in-
terface for quality of service related facilities, IFlowControlSignaling
for flow control interfaces, and IIndicator and IRequestPdu interfaces for
PDU based communication."

9.3.1.3.1 IAckConnectionless
9.3.1.3.5 AckConnectionlessLinkComponent
The definition of AckConnectionlessLinkComponent is not correct.
AckConnectionlessLinkComponent cannot be a specialization of
ConnectionlessLinkComponent since the PDU interfaces are different.


Recommendation:
Update Figure 9-65 IAckConnectionlessLink Definition to replace the
specializtion of ConnectionlessLinkComponent with
IQualityOfServiceConnectionless,
IFlowControlSignaling, and ILocalLinkManagement interfaces that are
realized by this component.


Replace 1st sentence in description of section
9.3.1.4.2ConnectionLinkComponent with "AckConnectionlessLinkComponent as
shown in Figure 9-65, realizes IAckConnectionlessLink and IErrorControl,
IQualityOfServiceConnectionless,
IFlowControlSignaling, and ILocalLinkManagement
interfaces.

The AckReplyPdu definition for the bind should be using ReplyHeaderType
type for the ControlHeaderType not RequestHeaderType in Figure 9-66
IAckReplyPdu, IAckIndicatorPdu and IAckRequestPdu Definitions.


Recommendation:
Update Figure 9-66 IAckReplyPdu, IAckIndicatorPdu and IAckRequestPdu
Definitions by replacing RequestHeaderType with ReplyHeaderType for the
IAckReplyPdu bind definition.

PIM and PSM Software Radio Components


Issue
9.3.1.1.1 ILocalLinkManagement
The getInfo operation does return any information and exceptions listed in
text description are undefined.


Recommendation
Replace void in getInfo operation with a return type. Update unbind
operations definition in operations section of 9.3.1.1.1
ILocalLinkManagement and Figure 9-62 ILocalLinkManagement Definition as
follows :


getInfo(in connectionID : ConnectionIDType, return InfoType): {raises
= (InvalidPort,
SystemError)}
This operation requests information of the provider about the currently
established connection. The connectionID parameter identifies a stream
(defined as a user connected to the provider). The operation may raise
the InvalidPort exception or SystemError exception.


Add InfoType, and InvalidPort and SystemError exceptions to types section
of 9.3.1.1.1 ILocalLinkManagement
The SCA API Supplement had InfoType define with 4 attributes: state,
sequence of modes, broadcast address, and address.  The appropriate
definition needs to be finalize as the outcome of this issue.

Discussion:
Replace void in getInfo operation with a return type. Update unbind
operations definition in operations section of 9.3.1.1.1
ILocalLinkManagement and Figure 9-62 ILocalLinkManagement Definition as
follows: 

getInfo(in connectionID : ConnectionIDType, return InfoType): {raises
= (InvalidPort,
SystemError)}
This operation requests information of the provider about the currently
established connection. The connectionID parameter identifies a stream
(defined as a user connected to the provider). The operation may raise
the InvalidPort exception or SystemError exception.

Add InfoType, and InvalidPort and SystemError exceptions to types section
of 9.3.1.1.1 ILocalLinkManagement
The SCA API Supplement had InfoType define with 4 attributes: state,
sequence of modes, broadcast address, and address.  The appropriate
definition needs to be finalize as the outcome of this issue.
Need more discussion on this issue. 2nd FTF will address the rest of this issue. 
Disposition:	Deferred   Resolution:
Annex D.1.5 was updated to match the specification. Specifically, the InfoType was added to the IDL DataLinkLayer namespace to agree with the current specification. Also, the StateType and ServiceModeType used by InfoType were added to the DataLinkLayer namespace. As a note, the Rose models associated with ILocalLinkManagement are being updated at the time of this resolution.

Issue: The UML Profile does not clearly state what is M1 and M2 data for
the UML Profile for SWRadio.
Recommendation:
Add the following statement in the UML Profile for SWRadio section. "M1
instances in the UML Profile for SWRadio is M2 data. This means specific
operation names (e.g., configure for PropertySet interface) or attribute
names (e.g., enabledLogLevels for SWRadioComponent) stated for  a component
or interface is M2 data. Extensions of UML metaclasses such as interface
(e.g., PropertySet), component (e.g., ResourceComponent), and device (e.g.,
CommunicationEquipment) are M1 elements."


This statement could also be stated in the compliance section for
implementations of the profile for tool providers.

.

Proposed resolution: This is a blanket issue for correcting the typos in the specification. Create a convenience document regarding all of the typos that were corrected. No technical changes should be made, only editorials.

When referencing SW Radio Components throughout this document, "WaveForm" and "Application" are not used consistantly. Many areas exist where components should be viewed as "Application" versus "WaveForm".  All "WaveForm" components are a true subset of "Application" components, while the reverse is not true.  Where components belong to the larger "Application" component set, "WaveForm" notation should be changed.

ApplicationFactory Should Provide the Option for Directly Configuring ApplicationResourceComponents 


Problem:
ApplicationFactory create () performs ALL configuration of ApplicationResourceComponent(s) EXCLUSIVELY through the assemblycontroller component.  ApplicationResourceComponent(s) should be provided with the option to be configured individually if so desired, followed by configuration of the assemblycontroller component after configuration of all ApplicationResourceComponent(s).


Proposed Solution:


1.  In section 8.3.4.2.2 (ApplicationFactory), modify the following paragraph


from 


"The create operation shall, in order, initialize ApplicationResourceComponent(s), then establish connections for ResourceComponents, and finally configures the Application's assemblyController."


to 


"The create operation shall, in order, initialize ApplicationResourceComponent(s), then establish connections for ResourceComponents, and finally configure the ApplicationResourceComponent(s).  The Application's assemblycontroller shall be configured after the configuration of all ApplicationResourceComponent(s)."



2.  After the above paragraph, add the following paragraph:


"The create operation configures an ApplicationResourceComponent, provided the ApplicationResourceComponent has ConfigureQueryProperty(s) described in the application's component assembly descriptor, with an isReadOnlyAttribute of False."



Rationale:


A component could have configuration properties that do not need to be known by the assembly controller.  Providing individual components the option to have their own configuration properties independent of being configured through an assembly controller, provides a higher degree of portability and genericism not only for the component, but also for the various assembly controllers.  The suggested behavior gives the option to waveform developers of how the initial configuration of the waveform should work. 

DESCRIPTION: 
Parameters of the IConnectionLink interface operations are not
correct/incomplete. establishStream operation should take source and
destionation address as input parameters. Furthermore, muxStreams should
return a streamID that is a reference to the multiplexed stream.
demuxSteams should return the streamID's of the demultiplexed streams. 
 
PROPOSED RESOLUTION:
Change the following operation descriptions from: 


"establishStream(streamID : ConnectionIDType)"
"muxStreams(streamID [2..n] : ConnectionIDType)"
"demuxStream(streamID : ConnectionIDType)"


to: 


"establishStream(in sourceAddress : AddressType, in destinationAddress :
AddressType, return streamID : ConnectionIDType)"
"muxStreams(in streamID [2..n] : ConnectionIDType, return muxStreamID :
ConnectionIDType)"
"demuxStream(in streamID : ConnectionIDType, return demuxStreamID [1..n]
: ConnectionIDType)"

DESCRIPTION: 
IPdu interface should specialize the IFlowControlSignalling interface
and not the IFlowControlManagement interface. 
 
PROPOSED RESOLUTION: 
In Section 9.2.5.3, (IPdu) pg 202, replace the following sentence:
"IPdu interface also specializes IFlowControl interface, so it supports
flow controlling."


to: 
"IPdu interface also specializes IFlowControlSignalling interface, so it
supports flow control signalling."


Also, update the UML model and Figure 9-60 (pg. 201) so that they show
the same specialization.

Currently, the SWRadio specification defines the CORBA/XML PSM definitions as mandatory. This does not allow for mapping the PIM to other platform technologies easily. Instead, make the transformation rules mandatory and provide PSM as informative. Also review chapter 10, and make sure that PIM-PSM translation rules are consistent and comprehensive. 

Discussion:
We will use OCL since QVT (Query View Transformation) spec (part of MOF2) is not out yet.  
We previously received some AB direction that PSM should be non-normative and the PIM - PSM translation should be normative. However, the QVT specification is not finalized yet, and there are no tools that would allow automatic translation of PIM to PSM. 
Need AB Comments on this. We would like to leave the PSM normative for now, and verbally state the translation rules. An RTF can handle the QVT transformation rules. 
Disposition:	Deferred    Resolution:
1.	Add sentences to sections 7 thru 10 to state, which sections are normative and which ones are non-normative.
2.	Change the title on all annexes to be non-normative.
Revised Text:

IScheduling was intended to be in the specification initially, but then we decided to leave it out. MAC Layer facilities and its component definition still refers to IScheduling interface even though it does not exist in the specification. 
 

localSetup operation of the IStream interface should take the streamID parameter at a minimum. It may also provide access to the parameters defined by the IQualityOfServiceConnection facility. 

Discussion:
The FTF needs to look into the overlap between this spec and the CCM Streams specification. FTF will look into CCM Streams revised submission.
Will be deferred since CCM revised submission that the resolution may take advantage of is delayed until April 2005 TC Meeting and the FTF has no time to explore other options at this juncture, with only 1 month prior to end of 1st FTF

Disposition:	Deferred     Discussion:
This issue is deferred to the follow-on RTF, since RTF #1 ran out of time.  
Disposition:	Deferred

Description: IO Facilities section Rose model defines a SerialIODeviceComponent and an AudioIODeviceComponent, but these components are never specified in the document. 
 
Proposed resolution: Create new subsections as 9.4.1.2 SerialIODeviceComponent and 9.4.2.2 AudioIODeviceComponent. specify which interfaces need to be realized and which ports are required.

Save the UML Profile for SWRadio into XMI when there is UML 2 tool support
that allows UML profiles creation and supports saving the profile as XMI.

Discussion:
We had several discussions with IBM, Zeligsoft and other UML tool vendors. 
We are waiting for OMG to decide what we are going to use for UML model exchanging.  After that, the SWRADIO FTF/RTF can decide how to go about resolving this issue.
Disposition:	Deferred

Two nested elements have the same name as their CORBA module name. The IDL
Compilers that were used for verification did not catch these errors.


CommonLayer CORBA Module
ErrorControl CORBA Module contains ErrorControl interface that conflicts
with the ErrorControl CORBA module name
Measurement CORBA Module contains the Measurement type that conflicts with
the Measurement CORBA module name


Proposed Solution


Common Layer Facilities
ErrorControl Facilities
Change named of ErrorControl interface to be Error_Control interface
Measurement Facilities
Change name of Measurement to be MeasurementType.


Updated Facilities and PSM based upon name changes.

Problem: Unable able to express the direction of a port for a
SWRadioComponent.


Proposed Solution: Add a direction property (TAG value) to the SWRadioPort
stereotype. Add direction tag value for SWRadioPort  in Table 8-3 Interface
and Port Stereotypes.


Add new section


8.1.3.2 SWRadioPort
Description
The SWRadioPort defines a  port that is associated with SWRAPIs.


Attributes
direction: DirectionType
The direction attribute indicates the usage direction of the port for a
component.


Types & Exceptions


<<enumeration>>DirectionType (IN, OUT, INOUT)
The DirectionType defines the direction values for a port.
      IN means data and/or control is received by a port
      OUT means data and/or control is sent by a port
      INOUT means ata and/or control is received and sent by a port


Constraints
The SWRadioPort is only associated with SWRadioAPIs.
A port with IN direction can only be connected to a a port with IN or INOUT
direction.
A port with OUT direction can only be connected to a a port with OUT or
INOUT direction.
A port with INOUT direction can only be connected to a a port with IN, OUT
or INOUT direction.


Semantics
The Direction for a port can be graphically illustrated by a background
color for each of  the Direction values.

Resolution:
As part of the resolution to issue 7953, a constraint has been added that states each port has a set of 1 required and 1 provided interface at most.  As such, there is no need for issue 7888, since the direction of the port is already implied based on whether the port is a uses or a provides port and the fact that the port is restricted to one interface only.  Hence, issue 7888 should be closed with no change required to the specification based on the resolution for issue 7953.
Revised Text:
N/A
Disposition:	Closed, no change

Problem: A port may have characteristics, such as throughput, latency,
non-blocking time, etc.


Proposed Solution: Add a characteristics property (TAG value) to the
SWRadioPort
stereotype. Add characteristics tag value for SWRadioPort in Table 8-3
Interface
and Port Stereotypes.


Related to issue 7888


Add to


Attributes section for SWRadioPort


characteristics : CharacteristicProperty [*]


The characteristics attribute defines the characteristics for a port.

Discussion:
Jerry:  
Add a characteristics property (TAG value) to the SWRadioPort stereotype. Add characteristics tag value for SWRadioPort in Table 8-3 Interface and Port Stereotypes.

Related to issue 7888

Add to Attributes section for SWRadioPort characteristics:  characteristicProperty [*]

The characteristics attribute defines the characteristics for a port.

December 9, 2004 FTF Telecon:  
·	Jerry requested to get group consensus before assignees proceed with the recommended resolution.  
·	John confirmed for Jerry that there is a QoS Profile in RT UML.  
·	Jerry:  We also want to look at QoS characteristics and see if want to add this to our list of characteristics, i.e. consider allowing a port to express what its characteristics are.
·	Jerry:  We need to look at an RTF to see if we want to have the RT UML profile updated as a part of UML 2.0.

Sunday January 30th, 2005, Burlingame Technical Meeting:
Neli took care of proposing the request to the RTESS RTAD WG and getting the above proposal into the group's RFP for the Burlingame Technical Meeting.

February 2, 2005 Burlingame Meeting:

Neli and Michael:  Provide rationale as to why this issue is being deferred to the RTF.  
Tansu:  Is not adding a characteristics property to a port allowing users to do whatever they want?
Michael:  Per the tag, if you read the model, you can tell that this component that has this port type can have this behavior.   
Tansu is concerned about the benefit of defining characteristics that no one but that component and that port understand.  
Michael:  This is a facility for defining port characteristics for possible future "registration".
Tansu:  If there is a minimum set of characteristics, they should be defined in addition to providing the proposed facility for defining more.  
Neli:  Where is the appropriate place for defining these minimum characteristics?
Tansu:  8.1.4 Interface and Port Stereotypes.  Currently no section for SWRadioPort, since it currently has no TAGs defined.  A new subsection must be added. 
See Eric Nicolet from Thales for a possible minimum set.  Eric.NICOLLET@fr.thalesgroup.com.  He presented his view of this minimum set of characteristic at the January SCA 3.1 Workshop.
Neli:  Finalized RTESS RFP for Adding QoS Characteristics to Ports, Burlingame Meeting February 2005. The UML Profile for MARTE RFP has been posted to the OMG server with the  document number realtime/2005-02-06 at URL
http://www.omg.org/cgi-bin/doc?realtime/2005-02-06

March 10, 2005 Telecon:
Neli and Jerry:  Handle just like the lack of descriptors in the specification.  As a resolution, point to the real time specification and expand to the full resolution in RTF.
Disposition:	Deferred
Discussion:
Per recommendation from and working with the SWRADIO FTF, the RTESS RTAD WG incorporated the desire for adding QoS characteristics to Ports into the UML Profile for MARTE RFP at the February 2005 Burlingame Technical Meeting, document number realtime/2005-02-06.  Hoping to resolve this issue by leveraging from the UML 2.0 Profile for MARTE (as opposed to defining such TAGs in the UML Profile for Software Radio), this issue is deferred pending the draft of the UML 2.0 Profile for MARTE specification which expresses QoS characteristics for Ports.

Problem: Now that the primitive types (issue 7656) are defined in the spec,
the duplicate definitions of these primitive types in the spec should be
removed when specified in other types sections in the spec. Also the usage
of integer in the spec should be replace with the appropriate primitive
type (short, long, ushort, etc.) in the spec in order to give precise
definition.


Solution: Replace integer where used in the spec with correct primitive
type (short, long, ushort, etc.). Removed redundant primitive types in
other sections in the spec. Types that are specialization of primitive
types should also be noted in the spec.

Problem: The display format for stereotype names when used at the M1 level
should be stated in the UML Profile and then consistently applied in the
specification.


Proposed Solution: Is to state the display format for stereotype names when
used at the M1 level is to use lower case letters for the stereotype name.
For example, stereotype name "ResourceComponent" would be represented as
<<resourcecomponent>>. Place these statements in section 8 intro paragraph.
Most of the usage in the specification uses lower case for the stereotype
display format.  UML 2.0 for DataType used this format <<dataType>>.  Also
make sure this format is applied consistently in the specification.

Discussion:
state the display format for stereotype names when used at the M1 level is to use lower case letters for the stereotype name.
For example, stereotype name "ResourceComponent" would be represented as <<resourcecomponent>>. Place these statements in section 8 intro paragraph.
Most of the usage in the specification uses lower case for the stereotype display format.  UML 2.0 for DataType used this format <<dataType>>.  Also make sure this format is applied consistently in the specification.

This issue spans the whole specification and needs to be handled by multiple people working on the specification. We hope to get to this issue once other issues are cleared during the second FTF
Disposition:	Deferred             Resolution:
Add text to end of section 7.0 for description of stereotype display format.

Problem: The start() and stop() operations introduce the following
ambiguity: What can a client expect the first time start() is called vs.
calling start() after a stop() call?  Is the component put in a known
state every time start() is called, or does it simply resume its
operation from the point where is received a stop(). In other words, the
semantics of the start->stop->start transition are ill-defined.


Proposed Solution:


Add a resume() operation to the interface to resolve this ambiguity.
Resume() would indicate that the component should continue its operation
from the point where stop() was issued. Start() would indicate that
component should be placed back in an "initial" state (at a point after
the LifeCycle::init() for components).  

Problem: PortExists is an operation on both DomainManager and
DeviceManager and can be factored out into a common interface.


Proposed Solution:
Either create a new interface to support this operation, or possibly add
the operation to PortSupplier

Problem:
Ports can have multiple provided and multiple required interfaces.  This complicates transforming a PIM to a CORBA PSM and encourages questionable architectures.  It is also confusing to implementers and users as shown by issues 7578 and 7579.
 
Proposed solution:
Constrain ports in the SWRadio PIM and PSM to have at most one provided interface and one required interface per port.

Problem: Figure 9-78 - Radio Set Facilities Overview. The
MangedServiceComponent Stereotype should be used as a stereotype for the
ManagedRadioManager and ManagedCommChannel components not a specialization
of.


Proposed Solution: Changed stereotype of ManagedRadioManager from
<<radiomanager>> to <<managedservicecomponent>>.  Changed stereotype of
ManagedCommChannel from <<commchannel>> to <<managedservicecomponent>>.
Remove specialize relationships from ManagedServiceComponent and remove
ManagedServiceComponent from figure. Update Figure 9-78 - Radio Set
Facilities Overview with changes.


Modify 9.6.1.3 ManagedCommChannel Description section
From
"The <<commchannel>> ManagedCommChannel component takes on the definition
as described in the UML Profile for SWRadio::Infrastructure::Radio
Management in addition to the specializations of the CommChannel
and ManagedServiceComponent (UML Profile for SWRadio::Infrastructure::Radio
Services)."
To
"The <<managedservicecomponent>> ManagedCommChannel component takes on the
definition as described in the UML Profile for
SWRadio::Infrastructure::Radio Services in addition to the specialization
of the CommChannel."


Modify 9.6.1.4 ManagedRadioManager Description section
From
"The <<radiomanager>> ManagedRadioManager component takes on the definition
as described in the UML Pro-
file for SWRadio::Infrastructure::Radio Management in addition to the
specializations of the RadioManager and ManagedServiceComponent (UML
Profile for SWRadio::Infrastructure::Radio Services). The
ManagedRadioManager provides the mechanism of a managed RadioManager with
state behavior."
To
"The <<managedservicecomponent>> ManagedRadioManager component takes on the
definition as described in the UML Pro-
file for SWRadio::Infrastructure::Radio Services in addition to the
specialization of the RadioManager. The ManagedRadioManager provides the
mechanism for a managed RadioManager with state behavior."

Issue 1 -  Property clean up



Problems
1.    RadioProperty has redundant attributes (name and description) that
are already described by a UML Property.
2.    SimpleProperty has redundant attributes (type and value) that are
already described by a UML Property.
3.    Remove SimpleType definition from SimpleProperty. Issue 7655 added
primitive types.
4.    The type for the SimpleProperty definition is not constrained to be a
set of SWRadio primitive types and the value is constrained either.
5.    The SimpleProperty’s optional range attribute min and max values are
not constrained to be compatible with the SimpleProperty’s type.
6.    ManagedCapability property name for ServiceProperty definition in
table 8-2 Properties Stereotypes (section 8.1.2 Properties) should be
capabilityModel.
7.    ServiceProperty needs a constrain that states a value is mandatory
when the locallyManaged attribute value is false.



Proposed Solutions
8.1.2 Properties Section


1.    Remove name and description attributes/tag values from Radio Property
definition in table 8-2 Properties Stereotypes (section 8.1.2 Properties).
Remove these attributes from section 8.1.2.9 RadioProperty (in Attributes
no header section).
2.    Remove type and value attributes/tag values from SimpleProperty
definition in table 8-2 Properties Stereotypes (section 8.1.2 Properties).
Remove these attributes from section 8.1.2.11 SimpleProperty (in Attributes
no header section).
3.    Remove SimpleType from Types and Exceptions in section 8.1.2.11
SimpleProperty.
4.    Add the following constraints in the 8.1.2.11 SimpleProperty
Constraints section that only valid primitive types that can be used for a
type and a constraint for the value.
·     The type shall be limited to the SWRadio primitive types (Boolean,
Character, Float, Double, Long, LongDouble, LongLong, ObjectReference,
Octet, Short, String, Ulong, ULongLong, UShort)
·     The value shall comply with the property type and range attribute
when specified.
5.    Add the following constraint in the 8.1.2.11 SimpleProperty
Constraints section that states the SimpleProperty’s range attribute min
and max values are constrained to be compatible with the SimpleProperty’s
type.
·     The range attribute min and max values shall be compatible with the
type and max shall be greater than or equal to min.
6.    Rename managedCapability tag with capabilityModel for ServiceProperty
in table 8-2 Properties Stereotypes (section 8.1.2 Properties).
7.    ServiceProperty section 8.1.210 add a constrain section with the
following constraint: “ServiceProperty shall have a value (not null) when
the locallyManaged attribute value is false.”

Problems
1.    Allow for the capability to form a TestProperty as a class, which
will allow a class to be used to form radio property definitions for
components. The current definition does not allow TestProperty definition
outside of the component.


Proposed Solutions
8.1.2 Properties Section


1.    Create a new TestDefProperty stereotype an extension of UML Class
metaclass that provides the capability of defining test property
definitions. Add a TestDefProperty entry to the table 8-2 Properties
Stereotypes in section 8.1.2 Properties that agrees with new definition in
TestDefProperty section. Add a new section before TestProperty subsection
in section 8.1.2 as follows:
      “Description
      The TestDefProperty, a type of Class as shown in Table 8-2, provides
      the capability to define the input parameters for the test and the
      results that can be returned for a test.
      Attributes
·     inputValue: SimpleProperty [*]
            The inputValue attribute defines the input parameters for a
            test (e.g., TestableObject::runTest).
·     resultValue: SimpleProperty [1..*]
            The resultValue attribute defines the expected results returned
            from a test (e.g., TestableObject::runTest).
      Constraints
·     Each inputValue name shall be unique.
·     Each inputValue value shall be specified (not null).
·     Each resultValue name shall be unique.
·     Each resultValue value shall be specified (not null).
2.    For TestProperty in section 8.1.2.15 remove the attributes section
and from table 8-2 Properties Stereotypes. Add a constraints section in
section 8.2.1.15 with the following constraint:
·     The type for a TestProperty shall be a TestDefProperty.
3.    Update Transform Rules in PSM section of specification



The following figure depicts the UML definitions
(Embedded image moved to file: pic30106.jpg)



(Embedded image moved to file: pic09040.jpg)

Problems
1.    Duplicate of configure and query property stereotypes in profile.
These concepts are defined for SWRadio components, interfaces and
communication equipment.
2.    Simplify the configure and query property definitions.
3.    Remove StructSequenceProperty and SimpleSequenceProperty. Not
necessary since multiplicity can be used following the type for primitive
and struct types.
4.    Allow for the capability to form a StructProperty as a class, which
will allow a class to be used to form radio property definitions for
components.


Proposed Solutions
8.1.2 Properties Section


1.    Define one ConfigureProperty Definition in section 8.1.2 Properties
·     Remove configquery item from the table 8-3 Interface & Port
Stereotypes.
·     Remove QueryProperty and ConfigureProperty subsections from Comm
Equipment section 8.2.4 Property.
·     Move MaxLatency attribute from ConfigQueryProperty subsection to
RadioProperty subsection in section 8.1.2. Update table 8-2 Properties
Stereotypes in section 8.1.2 Properties with same change.
·     Rename ConfigQueryProperty subsection in 8.1.2 Properties to
ConfigureProperty and the text description to be “The ConfigureProperty a
type of RadioProperty indicates a configurable and queryable property.
There are four types of ConfigureProperty, which are: primitive types,
primitive sequence types, StructProperty, and StructSequenceProperty. These
properties are described in the Base Types and the following subsections.”.
Also update name change and columns in table 8-2 Properties Stereotypes to
agree with definition. Make ConfigureProperty a concrete property type (not
an abstract property type).
·     Replace the constraints listed in the constraints noheader section as
follows:
i.    The type for ConfigureProperty shall be constrained to be primitive
types(), primitive sequence types (), or StructProperty.
ii.   The isReadOnly value shall be always set to false.


·     Remove ConfigureQuerySimpleProperty and ConfigureSimpleSeqProperty
subsections from 8.1.2 Properties and from table 8-2 Properties
Stereotypes.
·     Move optional range and units attributes from SimpleProperty
definition to the RadioProperty attributes definition.
2.    Add QueryProperty to section 8.1.2 Properties. Add a new row to table
8-2 Properties Stereotypes (as defined below) and add a new subsection
called QueryProperty in 8.1.2. Properties before RadioProperty as follows:
      Description
      The QueryProperty, a type of RadioProperty as shown in Table 8-2,
      provides the capability to define a read-only property that can be
      queried at run-time by a control command. It cannot be modified by a
      control command.
      Constraints
i.    The type for QueryProperty shall be constrained to be a primitive
types (), primitive sequence types, StructProperty.
ii.   The isReadOnly value shall be always set to true
3.    Change StructProperty definition.
·     Make StructProperty stereotype an extension of UML Class metaclass
instead of UML Property that provides the capability of defining structure
property definitions.
i.    8.1.2.13 StructProperty Modifications
i.    Replace the description with “The StructProperty is a type that
contains a list of SimpleProperty.
ii.   Change the multiplicity to “*” instead of “1..*” in attributes
iii.   Modify the Constraints section as follows:
a.    Replace first constraint with “Each attribute name must be unique
within the StructProperty.”
b.    Add Constraint - Attributes can only be primitive data types and can
be stereotyped as SimpleProperty.
c.    Remove existing second constraint.
ii.    Table 8-2 Properties Stereotypes in section 8.1.2 Modifications
i.    Properties Change the base class for StructProperty to Class
ii.   Place N/A in Parent Class Column.
4.    Remove StructSequenceProperty and SimpleSequenceProperty from section
8.1.2 Properties.
5.    Change CharacteristicSetProperty to be constrained to the
StructProperty type for its type. This allows any characteristic set to be
expressed. Remove CharacteristicQualifiers and CharacteristicQualifier from
types sections in CharacteristicSetProperty section 8.1.2.4.
6.    Make CharacteristicSelectionProperty a type of SimpleProperty with
multiple values since SimpleSequenceProperty is being removed.


Other Proposed Solutions
7.    Update I/O Facilities to use the new Configure and Query Property
Stereotypes.
8.    Update Physical Layer Facilities to use the new Configure and Query
Property Stereotypes.
9.    Update UML Profile for SWRadio to use the new Configure and Query
Property Stereotypes.
10.   Update Transformation Rules in the PSM section

From 8.3.2, section Description: "The LogicalCommunicationChannel, shown in
which inherits from an abstract Channel class is logically partitioned into
three groups: the LogicalRFChannel, the LogicalProcessingChannel, and the
LogicalIOChannel. "
According to Figure 8-32, This should have four groups as follows.: the
LogicalProcessingChannel,, the LogicalIOChannel, the LogicalPhysicalChannel
and the SecureLogicalCommunicationChannel.


Proposed Solution:
Change the sentence to read as follows:
"The LogicalCommunicationChannel, shown in which inherits from an abstract
Channel class is logically partitioned into three groups: the
LogicalPhysicalChannel, the LogicalIOChannel , the LogicalProcessingChannel,
and the SecureLogicalCommunicationChannel. "

Resolution:
Reject the issue, since SecureLogicalCommunicationChannel is a extension of LogicalCommunicationChannel not an aggregate
Revised Text:
N/A
Disposition:	Closed, no change

"Each LogicalIOChannel shall have only one IODevice"  A single
LogicalIOChannel should be capable of having more then one IODevice.


Proposed Solution:
Change the association in question to read as"
"Each LogicalIOChannel shall have at least one IODevice."

"A logicalIOChannel may be associated with zero or one processor."
A single IO channel should be capable of being associated with more then on
processor. A simple example would be a system working with an FPGA and a
GPPU.


Proposed Solution:
Change the association in question to read as:
"A logicalIOChannel may be associated with zero or more processors."

{communication channel requires at least one of an RF channel or an I/O
channel}
There is neither a description of a "RF channel" nor a "communication
channel" in the specification.


Proposed Solutions:
Rework the constraint to read as: {LogicalCommunicationChannel requires at
least one of a SecureLogicalCommunicationChannel, LogicalPhysicalChannel,
LogicalIOChannel, or LogicalProcessingChannel.}

Discussion:
Reject the issue, since SecureLogicalCommunicationChannel is a extension of LogicalCommunicationChannel not an aggregate
Revised Text:
N/A
Disposition:	Closed, no change

Throughput is listed as a double but this will not suffice for channels
capable of supporting multiple thoughputs like Ethernet or USB.


Proposed Solution:
Suggest changing this to maxThroughput or another type that would allow for
a series of max throughputs.

Problem:  Currently enumeration types are defined as a TAG in a
simpleproperty. This has two levels of definition, which are enumerations
and their values and then the assigned value to be used for the property.


Solution: Add the capability of defining a SWRadio enumeration type to
allow this type to be used for configure, query, characteristic, and struct
definitions.
 Remove enumeration literal from simple property definition and form a
enumeration type where the literals have assigned values.  This will also
allow the type to be used by other property definitions

Problem:
Common Radio Facilities now has no text in it since the File Services got
removed from the section.
Solution:
Either add text in the section by referring to OMG LW Services or remove
section

Verify that the audio types are correct as being float.


Solution: If the audio types are not suppose to be floats then change them
to the correct type (e.g. integer types).  If the audio attribute types can
be viewed to have multiple solutions then make an audio component template
and do a bind relationship to it with types that are appropriate

The compliance section defines compliance points, but it needs to be specifically point out which sections constitute each compliance point. 

Proposed resolution: Create a table for each compliance point and refer each compliance point to a list of specific sections 

Discussion:
Create a table for each compliance point and refer each compliance point to a list of specific sections. 
We ran out of time, since this issue came in after the comments deadline. This is an important issue since it affects the compliance criteria to the spec and needs clarification. 2nd FTF will address this issue. 
Disposition:	Deferred     Resolution:
In PIM and PSM for SWRadio Components, text will be added to point to sections and volume specs. Issue 8259  is also addressing compliancy.

Refine the waveform compliance to interface level and component level waveform compliance. 

Interface level compliance is more "loose" and can be used by existing SCA CF implementations or in other communication domains that make use of a different infrastructure for component communication/management. Component level compliance requires implementation of the infrastructure as well.

Proposed resolution: Create 2 waveform compliance points: interface level and component level. Point out the differences. 

Discussion:
Create 2 waveform compliance points: interface level and component level. Point out the differences 
We ran out of time, since this issue came in after the comments deadline. This is an important issue since it affects the compliance criteria to the spec and needs clarification. 2nd FTF will address this issue. 

Disposition:	Deferred
Resolution:
The compliance level is described in terms of component instead of specifically to just waveform compliance. Wording changes will be added to the PIM and PSM SWRadio Spec, Component Framework, Communication Channel, and Common and Data Link Layer Facilities Volumes.

Issue: 7983, 7984, and 7985 did not include mods to the PSM transformation
or XML changes in Section I


Proposed Resolution: Update item 3  in section 10 PSM for the
transformation of properties to XML and update  Section I in the appendix A

The IDL in Appendix needs to be updated to agree with Facilities
      definition as defined in section D.1.5 Data Link Layer Local
      Management,
      section D.1.3 Data Link Layer Connection Interface, and section B.5
      PDU
      Interfaces .



      The statement of "Verify that the data link component definitions are
      in sync with section
      B.5 PDU Interfaces changes introduced in Issue 7789." is not an issue
      at this time but a comment.

Discussion:
The IDL in Appendix needs to be updated to agree with Facilities definition as defined in section D.1.5 Data Link Layer Local Management, section D.1.3 Data Link Layer Connection Interface, and section B.5 PDU Interfaces.

The statement of "Verify that the data link component definitions are in sync with section B.5 PDU Interfaces changes introduced in Issue 7789." is not an issue at this time but a comment.

The IDL in Appendix needs to be updated to agree with Facilities definition
as defined in section D.1.5 Data Link Layer Local Management, section D.1.3
Data Link Layer Connection Interface, and section B.5 PDU Interfaces .

Original Issue Resolution by Jerry:
OMG Issue No: 7789:Yes, but a new issue needs to issue to change data link
component definitions and the IDL in section B.5 PDU Interfaces needs to be
updated or an amendment to this vote. This has to be completed for vote 3.

Verify that the data link component definitions are in sync with section
B.5 PDU Interfaces changes introduced in Issue 7789.
SWRadio FTF will handle this in the 2nd FTF timeframe. 
Disposition:	Deferred
Resolution:
The IDL is updated with respect to the Rose models in the specification. Specifically, Annexes B.5, D.1.2, D.1.3, D.1.4, and D.1.5 have been updated to match the specification. 

Proposed Solution:

This issue is a followup to 7715 which can be closed without change due to 7708.

Issue 7708 replaced DigitalConverter by Converter (with a converterType property indicating ATOD, DTOA or BOTH).  There are still references to DigitalConverter in the document.  Page and section references refer to the 2005-02-24 SWRadio Convenience Document.

* In row 4 of Table 8-7 on page 101,
    * Replace DigitalConverter with Converter
    * Add converterType to the head of column 4
    * In Figure 8-35 on page 143, replace DigitalConverter with Converter
    * In 8.3.2.3 LogicalPhysicalChannel - Associations on page 143, replace both uses of DigitalConverter with Converter

Discussion:
Issue 7708 replaced DigitalConverter by Converter (with a converterType property indicating ATOD, DTOA or BOTH).  There are still references to DigitalConverter in the document.  Page and section references refer to the 2005-02-24 SWRadio Convenience Document.

* In row 4 of Table 8-7 on page 101,
    * Replace DigitalConverter with Converter
    * Add converterType to the head of column 4
    * In Figure 8-35 on page 143, replace DigitalConverter with Converter
    * In 8.3.2.3 LogicalPhysicalChannel - Associations on page 143, replace both uses of DigitalConverter with Converter
We ran out of time, since this issue came in after the comments deadline. This is an important issue since it affects the compliance criteria to the spec and needs clarification. 2nd FTF will address this issue. 
Disposition:	Deferred  Resolution:
Remove DigitalConverter from spec and fix Communication Equipment Stereotype table.

Undefined Types


Issue: There are three types used in the Communications Equipment section of
the PIM/PSM for SWRadio that are undefined (which need basic type
definition):


1. AmplitudePhaseResponse: The amplitudePhaseResponse attribute gives the
amplitude/phase response plot for the device. The amplitude phase response
contains two components.  The first component is a representation of the
output power versus the input power.  The second component is a
representation of the output phase versus input power.  The purpose of the
amplitude phase response is to describe any active element which cannot be
described by an ideal relationship (non linearities) e.g.: Power Amplifier.


2. Radiation: Information about a specific radiation environment.


3. SwitchSetting: Indicates the connections between the switch's ports.


Proposed Solution: In discussion with other members of the FTF, it is felt
that subject matter experts in these areas (particularly the original
authors) could evaluate the context of these types and recommend the correct
definition.

Discussion:
Mark: In discussion with other members of the FTF, it is felt that subject matter experts in these areas (particularly the original authors) could evaluate the context of these types and recommend the correct definition.

March 10, 2005 Telecon:
Tansu:  Should resolve in 2nd FTF if there's time, since the specification is pointing to types that do not exist.  
Disposition:	Deferred   Resolution:
§	Define Radiation Type as a float.
§	Define SwitchSetting as a sequence of SwitchMapping.
§	Define AmplitudePhaseResponse
§	Raise issue for AM-PM amplitude phase levels

The SWRadio UML model is not mentioned in the SWRadio specification. Add a non-normative reference in the convenience document for the UML model. Add a paragraph explaining that the UML model is non-normative at the end of Section 6.2.

Summary: pthread_atfork() not required
Proposed Solution: remove operation from being a mandatory part of the AEP
in Annex H
Rationale: Since the function fork() is not required, it does not make sense
to require support of pthread_atfork().

Resolution:
Remove operation from being a mandatory part of the AEP in Annex H.
Add pthread_atfork() operation to the list of not required functions.
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #183.  

Summary: In section 8.3.1.4.3 (FileSystem)
Add the following new requirements


"If the destination file already exists, the copy operation shall overwrite
the destination file."


"The copy operation shall raise the InvalidFileName exception when the
destination filename is identical to the source filename (i.e. attempting to
copy on top of itself)."
Rationale: Provide guidance for copy behavior when the target file exists.

Resolution:
The first suggested clarification is accepted with the added caveat that the source and destination file names are different.
The second suggested clarification (disallowing copying onto yourself) follows what POSIX and most of other OS's have for this behavior.   Copying the exact same file name can be allowed if there are different directory paths but if the path and filename are exactly the same between the source and destination this is not allowed.  The typical implementation of an overwrite is to delete the file first and then copy in the new file ... And, thus the problem, if you delete what you are copying what is left to copy?  In this case, the destination file should remain untouched.
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #152.  

Summary: Add function to AEP
The requirements for functions grouped under {_POSIX_THREAD_SAFE_FUNCTIONS}
are listed in the SCA AEP (Appendix H), Missing from the list is the
readdir_r( ) function. readdir_r( ) is described as a member of
{_POSIX_THREAD_SAFE_FUNCTIONS} in Section 5.1.2 of ISO/IEC 995-1:1996. This
function should be added in table H-41


Rationale: All other functions in the {_POSIX_THREAD_SAFE_FUNCTIONS}group
are listed in the SCA AEP, whether required or not. In addition, readdir_r(
)'s 'non-thread safe' cousin, readdir( ), is listed as Mandatory

Add missing function referenced in problem description to table H-41
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #163

Summary: Non-existent file creation mask
In section H.1.3.1.7 File Attributes Function Behavior
Change creation mask to POSIX defined "S_IRWXU" vice "SS--IIRRWWXXUU". (Note
the use of the underline (_) vice hyphen(-).) 


Rationale: Section A.3.1.7 of the IEEE Std 1003.13-1998 (from which the SCA
AEP was paraphrased) describes a file mode creation mask of "S-IRWXU" (even
this is in error, should be "S_IRWXU".) POSIX contains a set of binary
constants in the sys/stat.h header file for use by file creation functions,
one of which is "S_IRWXU" (see IEEE Std 1003.1 or ISO/IEC 9945-1, section
5.6.1.2). Binary constant "S_IRWXU" provides the required full accessibility
to the creator of the file.

In section H.1.3.1.7 File Attributes Function Behavior
Change creation mask to POSIX defined "S_IRWXU" vice "SS--IIRRWWXXUU". (Note the use of the underline (_) vice hyphen(-).)
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #161

Summary: Add Non-existent section header
Change From:
H.1.3.3.1 Re-entrant User Group Function Behavior.
The function listed in Table H-38 shall behave as described in the
referenced clause.
Table H 38.  POSIX_USER_GROUPS_R Function
Function        Reference in POSIX.1c   SCA AEP
getlogin_r()    4.2.4   NRQ


NOTE:
NRQ - Not required for this profile.


Table H 39.  POSIX_DEVICE_SPECIFIC_R Function
Function        Reference in POSIX.1c   SCA AEP
ttyname_r()     4.7.4   NRQ


NOTE:
NRQ - Not required for this profile.


To:
H.1.3.3.1 Re-entrant User Group Function Behavior.
The function listed in Table H-38 shall behave as described in the
referenced clause.
Table H 38.  POSIX_USER_GROUPS_R Function
Function        Reference in POSIX.1c   SCA AEP
getlogin_r()    4.2.4   NRQ


NOTE:
NRQ - Not required for this profile.


H.1.3.3.2 Re-entrant Device Specific Function Behavior.
The function listed in Table H-39 shall behave as described in the
referenced clause.
Table H 39.  POSIX_DEVICE_SPECIFIC_R Function
Function        Reference in POSIX.1c   SCA AEP
ttyname_r()     4.7.4   NRQ


NOTE:
NRQ - Not required for this profile.


Rationale: Specification Correctness

Resolution:
Change From:
H.1.3.3.1 Re-entrant User Group Function Behavior.
The function listed in Table H-38 shall behave as described in the
referenced clause.
Table H 38.  POSIX_USER_GROUPS_R Function
Function         Reference in POSIX.1c   SCA AEP
getlogin_r()    4.2.4    NRQ

NOTE:
NRQ - Not required for this profile.

Table H 39. POSIX_DEVICE_SPECIFIC_R Function
Function         Reference in POSIX.1c   SCA AEP
ttyname_r()     4.7.4    NRQ

NOTE:
NRQ - Not required for this profile.

To:
H.1.3.3.1 Re-entrant User Group Function Behavior.
The function listed in Table H-38 shall behave as described in the
referenced clause.
Table H 38.  POSIX_USER_GROUPS_R Function
Function         Reference in POSIX.1c   SCA AEP
getlogin_r()    4.2.4    NRQ

NOTE:
NRQ - Not required for this profile.

H.1.3.3.2 Re-entrant Device Specific Function Behavior.
The function listed in Table H-39 shall behave as described in the
referenced clause.
Table H 39.  POSIX_DEVICE_SPECIFIC_R Function
Function         Reference in POSIX.1c   SCA AEP
ttyname_r()     4.7.4    NRQ

NOTE:
NRQ - Not required for this profile.
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #160.  

Summary: Correction of references and editorial change
In section H.1.3.3
Change section reference from A.3.3 to H.1.3.3


Also editorially, base the annex table references from H-1 and not H-15


Rationale: correctness

In section H.1.3.3
Change section reference from A.3.3 to H.1.3.3

Also editorially, base the annex table references from H-1 and not H-15
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #159

Summary: Modify POSIX spec references
In section H.1.2 
Table H 15.  Required Standards readjust the specification values
Standard                               SCA AEP
C Standard (ISO/IEC 9899:1990)  PRT
POSIX.1 (ISO/IEC 9945 -1:1996)  PRT
POSIX.1b (ISO/IEC 9945 -1:1996) PRT
POSIX.1c (ISO/IEC 9945 -1:1996) PRT
POSIX.5b (IEEE 1003.5 - 1992)   OPT


Rationale: Points the specification to dated, but valid, editions of the
POSIX spec, a future project needs to refresh the spec references.

In section H.1.2 
Table H 15.  Required Standards readjust the specification values
Standard SCA AEP
C Standard (ISO/IEC 9899:1990)  PRT
POSIX.1 (ISO/IEC 9945 -1:1996)  PRT
POSIX.1b (ISO/IEC 9945 -1:1996) PRT
POSIX.1c (ISO/IEC 9945 -1:1996) PRT
POSIX.5b (IEEE 1003.5 - 1992)   OPT
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #156.  

In section 8.3.3.1.1.2 DomainInstallation remove:
The uninstallApplication operation shall remove all files associated with
the Application.


(Semantics)change from:
An installer service typically invokes these operations when adding or
removing an ApplicationFactory (installedApplication) from the domain.
to:
An installer service typically invokes these operations when adding or
removing an ApplicationFactory (installedApplication) after creating or
prior to deleting the 
associated application files.


Rationale: Simplifies DomainManager::uninstallApplication and makes it
symmetrical to installApplication.

Modify the DomainInstallation interface uninstallApplication operation and Semantics sections to not require the removal of application files.
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #149.  

Summary: Wording changes to capture all AEP requirements
In section H.1.3
In the first paragraph under B.3 CONSTRAINTS, change the last sentence 
From:
This clause defines the constraints that an application strictly conforming
to one of the profiles shall observe when using each of the functions
required by that profile.
To:
This clause defines the constraints that an application strictly conforming
to one of the profiles must observe when using each of the functions
required by that profile.


In H.1.3.2 POSIX.1b, change the introductory sentence 
From:
Table H-36 contains the required options, limits, and any other constraints
on POSIX.1b.
To:
The options, limits, and any other constraints on POSIX.1b shall be provided
as described in Table H-36.


In H.1.3.3 POSIX.1c, after the introductory sentence and above Table H-37,
add the sentence:
The options, limits, and any other constraints on POSIX.1c as described in
Table H-37 shall be provided.


Rationale: Improve the accuracy of the specification

In the first paragraph under B.3 CONSTRAINTS, change the last sentence 
From:
This clause defines the constraints that an application strictly conforming
to one of the profiles shall observe when using each of the functions
required by that profile.
To:
This clause defines the constraints that an application strictly conforming
to one of the profiles must observe when using each of the functions
required by that profile.

In H.1.3.2 POSIX.1b, change the introductory sentence 
From:
Table H-36 contains the required options, limits, and any other constraints
on POSIX.1b.
To:
The options, limits, and any other constraints on POSIX.1b shall be provided
as described in Table H-36.

In H.1.3.3 POSIX.1c, after the introductory sentence and above Table H-37,
add the sentence:
The options, limits, and any other constraints on POSIX.1c as described in
Table H-37 shall be provided.
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #133.  

Section 8.3.3.1.1.3, Device Manager registration, add the following text 


"The registerDeviceManager operation shall return without exception and not
register a new DeviceManager when a registering DeviceManager has the same
identifier (i.e. its deviceconfiguration element id attribute) as a
registered DeviceManager and the reference to the registered DeviceManager
is not a dangling reference (i.e. it refers to an existing object). The
registerDeviceManager operation shall unregister the registered
DeviceManager prior to registering the new DeviceManager if the reference to
the registered DeviceManager having the same identifier is a dangling
reference."


The registerService operation shall return without exception and not
register a new service when a registeringService has the same name and type
as a registered Service and the reference to the registered Service is not a
dangling reference (i.e. it refers to an existing object). The
registerService operation shall unregister the registered Service prior to
registering the new Service if the reference to the registered Service
having the same name and type is a dangling reference.


Recommendation for duplicate application installations:
8.3.3.1.1.2 DomainInstallation
Add new text:


ApplicationAlreadyInstalled


The ApplicationAlreadyInstalled exception indicates that the application
being installed is already installed.


exception ApplicationAlreadyInstalled{};


Add new paragraph to section (Exceptions)
The installApplication operation shall raise the ApplicationAlreadyInstalled
exception when the registering application's identifier (i.e. its
softwareassembly element id attribute) is the same as a previously
registered application.


Make corresponding changes to the IDL.


Rationale: Simplifies DomainManager::uninstallApplication and makes it
symmetrical to installApplication.

Modify the DomainInstallation interface installApplication operation to treat duplicate installation requests as an error indicated by the existing ApplicationInstallationError exception.  
The DomainInstallation interface specification text does not show the correct synopsis for the ApplicationInstallationError exception, even though the synopsis is correct in the PSM, the Rose Model, and the IDL.  The errorNumber and msg attributes need to be added to the exception's synopsis.
Modify the DeviceManagerRegistration interface registerService operation synopsis to reflect registration of a ServiceComponent type for the registeringService parameter, (instead of the Service type).  The parameter type in the Rose Model is correct.
Modify the DeviceManagerRegistration interface semantics section to refer to registration of ServiceComponent(s) and ManagedServiceComponent(s), instead of registration of Service(s) and ManagedService(s).
Modify the DeviceManagerRegistration interface semantics section to state that the registerDeviceManager and registerService operations' behavior with respect to duplicate registration requests (i.e. ignoring the request or treating the request as an error) will be up to the PSMs, PIMs, or profiles that extend the SWRadio profile. 
This resolution is partially based on JTRS SCA TAG SCA 2.2 Change Proposal #122.  

Summary:  registerDeviceManager description conflict 
(registerDeviceManager), concepts
The registerDeviceManager operation shall establish any connections
specified in the connections element of the deviceMgr's Device Configuration
Descriptor (DCD) file that are possible with the current set of registered
devices and services --others are left unconnected pending future service
registrations. The registerDeviceManager operation shall establish any
pending connections from previously registered DeviceManagers  if any of the
newly registered Services complete these connections.


(unregisterDeviceManager) concepts
The unregisterDeviceManager operation shall disconnect the established
connections (including those made to the CORBA Event Service event channels)
involving the unregistering DeviceManager. Any such broken connections to
components remaining from other DeviceManager's DCD files shall be
considered as "pending" future connections. 


(unregisterService) concepts
The unregisterService operation shall disconnect any connections to the
named Service.  Such connections to the remaining components shall then be
considered as "pending" future connection.


Rationale: Clarification of existing text, more complete specification of
services, and not precluding device to device connections.

1.	The register operations need to explicitly and more clearly specify that all connections to the registering entity's service(s) that can be satisfied with entities currently registered with the domain must be established and any remaining connections must be viewed as pending until the services that can satisfy them are registered with the domain.
2.	The register operations should not preclude the possibility that a service from a different DeviceManager may be able to satisfy the connection specification in another DeviceManager. 
3.	The unregister operations need to explicitly and more clearly specify the need to disestablish all connections, including those for an event channel, from the unregistering entity.  They must furthermore specify that any broken connections to the unregistering entities (from either the unregistering or other DeviceManager(s)) will be considered as pending until they can be satisfied by other registering entities.
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #108.  

From:
The create operation shall only use Service(s) that have been granted
successful capacity allocations for loading and executing Application
components, or used for data processing.


To:
The create operation shall only use Service(s) that satisfy the allocation
requirements specified for the Application components.


Rationale: better aligns allocation with concept of capacities and
characteristics.

In the proposed resolution, instead of referring to Application components "allocation requirements", use the term "deployment and partitioning requirements", as those are the requirements that must be satisfied by candidate Service(s).  Furthermore, clarify that capability and capacity characteristics for a Service component are expressed in the Service component's ServiceProperties.
This resolution is based on JTRS SCA TAG SCA 2.2 Change Proposal #120.  

The SCA is attempting to move in a direction away from composite, aggregate
devices. The SCA approach may not be the wisest, but it has chosen to
express the concept in terms of parent and children. 
If theses are not acceptable terms then whole/part or aggregate/component
part may be reasonable alternatives. One reason for doing this is that the
terms composite and aggregate have definitions in the UML spec that exceed
the intended capabilities of this relationship.


Rationale: Clarify composite behavior.

The basic resolution is to replace the term Aggregate Device with Device Composition.  The behavior specified throughout the profile and PIM is consistent with a Composite association.  Wording, diagrams, and associated component sections should be updated to reflect this renaming.  Introduce the term composite part to qualify the device components that are added to the composition.  Rename the Device Aggregation component section to identify a Device Composition Component stereotype to reflect the composition behavior.  Add an associated diagram for this component.  Update the IDL to reflect the name change as well.

The sentence in ApplcationFactory "The deployed
Application's ApplicationResourceComponents configuration property
values shall only come from the Application's descriptor, not from an
ApplicationResourceComponent's implementation or component definition
descriptors." should not be restrictive to ApplicationResourceComponents
but to any SWRadioComponents deployed

Configuration of components created by an ApplicationFactory should not be restricted to ApplicationResourceComponents.  AppliationFactory should configure any created component that supports the PropertySet interface.  The same rule must also be observed for initialization and connection of any ApplicationFactory-created component.  The ApplicationFactory should initialize all components that support the LifeCycle interface and should connect all components that support the PortConnector interface.   This flexibility promotes development of lightweight components where supporting all Resource Component interfaces (i.e. PortConnector, PortSupplier, ControllableComponent, ComponentIndentifier, LifeCycle, PropertySet, and TestableObject) is not needed.

The issue resolution for Issue 7786 should be also true for DeviceManager's
property configuration of deployed service components.


The DeviceManager's deployed ServiceComponents configuration property
values shall only come from the DeviceManager's descriptor, not from an
ServiceComponent's implementation or component definition
descriptors

Configuration of components created by a DeviceManagerComponent should not be restricted to ResourceComponents.  The DeviceManagerComponent should configure any created component that supports the PropertySet interface.  The same rule must also be observed for initialization of created components.  The DeviceManagerComponent should initialize all components that support the LifeCycle interface.   This flexibility promotes development of lightweight components where supporting all Resource Component interfaces (i.e. PortConnector, PortSupplier, ControllableComponent, ComponentIndentifier, LifeCycle, PropertySet, and TestableObject) is not needed.

Proposed Solution: Add a section in the PSM that describes the PSMs (SCA,
and Deployment and Configuration) that could be used for component
descriptors for SWRadioComponents. Use the following table for this
information.



|---------------------------+------------------+------------------|
| SWRadio Component         | SCA DTDs         | Deployment &     |
|                           |                  | Configuration XSD|
|---------------------------+------------------+------------------|
| ApplicationManager        |                  |                  |
|---------------------------+------------------+------------------|
| ApplicationFactoryComponen|                  |                  |
| t                         |                  |                  |
|---------------------------+------------------+------------------|
| DeviceManagerComponent    |                  |                  |
|---------------------------+------------------+------------------|
| DomainManagerComponent    |                  |                  |
|---------------------------+------------------+------------------|
| SWRadioComponent          |                  |                  |
|---------------------------+------------------+------------------|




The section should reference a separate spec for the SCA DTDs. This spec is
part of the swradio specification. This spec needs to state the mapping of
the profile to the DTDs.


Followup work would to map the DTDs to D & C XSD

Resolution:
4.	Add item 4 to non-CORBA PSMs in section 10 that references the CCM Schema XML and DTDs that are used in software radios.  The DTDs will be added as an annex L.
5.	Add a new separate spec as part of the SWRadio spec that is Annex L.
6.	Machine Files for DTDs.
JTRS SCA TAG SCA Change Proposals for the resolution for this issue:
OMG document DTC/2005-09-07

Time type definition more than once in spec. Also RadioProperty
IntegerId property is a string instead of an integer type.  Range type may
also be duplicated in spec.


Proposed Solution: CommEquipment and CommonLayer section needs to replace
Time (or TimeType) with TimeType and remove Time (or TimeType) from these
sections. Update SWRadioFacilities as necessary to use TimeType from
BaseTypes.


Change radioProperty's integerId type from string to Unsigned short

Resolution:
1.	Use the TimeType definition in BaseTypes and remove duplicate definition in specification in CommonLayerFacilities and CommEquipment.
2.	Updated rose model for ProgrammableLogicDevice to use TimeType.
3.	Updated spec and rose for RadioProperty's integerID attribute
Revised Text:

Use of Float and Double types for CommEquip and PhysicalLayer
Facilities. During the Athens meeting there was discussion to use a integer
type instead.


Proposed Solution: is to make type changes as appropriate in the Comm
Equipement and Modem and Physical Layer Facilities.


Examples frequency, meter, etc.

Discussion:
At the 2006 OMG St. Louis TC meeting went through the comm. Equipment types and no type changes were done or suggested for float or double types to integer types.
Disposition:	Closed, no change

There are still some types not defined in the spec or should be
modified, continuation from 7895


1)ArchitectureType make a
EnumerationProperty as an unsigned integer with some defined types. This
allows for growth without changing type. 2)Types that are specializations
are not
defined in rose profile. 3) General question, now that we have
EnumerationProperty type which enumeration types (e.g., CryptoAlgorithm,
ArchitectureType. etc.) should be modified to be EnumerationProperty
instead, so integer values can used instead of strings.  4)
OperatingEnvironmentDescription is more of a CharacteristicSetProperty
than a string. 5) PhaseNoise not defined 8) PlugAndPlayInformation a
better type name

Resolution:
During the 2006 OMG TC St, Louis Meeting, all comm. Equipment types were reviewed.
The following definitions were modified as follows:

§	Remove Range Type
§	Change Frequency to Hertz
§	Make  AntennaType a specialization of String
§	Make ArchitectureType a specialization of String
§	Make CryptoAlgorithm a specialization of String
§	Make DistrubutionType a specialization String
§	Add Degrees definition, a specialization of Float.
§	Add FrequencyReponse definition
§	Modify Impedance definition
§	LogicUnit Type modification
§	PhaseNoise Definition
§	RadiatingElementType
§	Replace dB with Decibel
§	Remove OperatingEnvironmentDescription

The elements defined in this section
need to be an extension not a specialization of LiteralSpecification


Proposed Change: Changed 2nd sentence  in section 8.1.2 by changing the
word of "specializations" to "extensions"


In the rose model, change the specialization relationship to extension

Resolution:
1.	Make LiteralSpecification types an extension of LiteralSpecification instead of a specialization.
2.	Updated Section 8.1.2 LiteralSpecification and rose model

Throughout the specification, there are references to
the non-existent property type, ConfigureQueryProperty, where there is
need to refer to a "configurable" as well as "queriable" property.  The
correct type to reference is ConfigureProperty.  Furthermore,
ConfigureProperties already have a constraint to have their isReadOnly
attribute to be false.  There is no need to have this constraint
re-iterated where a ConfigureProperty is referenced.


Proposed Resolution:  Replace all existing references to the
ConfigureQueryProperty type with the ConfigureType in the specification
text.  Described errors do not exist in the UML model or the IDL.  Where
ConfigureProperty is used, remove the statement of isReadOnly attribute
being false, as that is already part of the definition of this property
type.


Rationale:  Correctness and removal of redundant information

Resolution:
Replace all existing references to the ConfigureQueryProperty type with the ConfigureType in the specification text.  Described errors do not exist in the UML model or the IDL.  Where ConfigureProperty is used, remove the statement of isReadOnly attribute being false, as that is already part of the definition of this property type.

Issue: Application releaseObject Disconnect Behavior
Limit what ports need to be disconnected during release of an
ApplicationManager.


Rational:


The application resource component
releaseObject can cleanup without the need to call disconnect on each
individual port. Efficiency


ApplicationManager Semantics


from


"The releaseObject operation shall disconnect port connections that have
been connected based upon the Application's component assembly descriptor.
"



to


" The releaseObject operation shall disconnect port connections to
non-application component providers (e.g.,
that have been connected based upon the Application's component assembly
descriptor."



Lifecycle releaseObject operation
from
   "The releaseObject operation shall release all internal memory allocated
               by the component"
to
        "The releaseObject operation shall release all internal memory
allocated and connections by the component"

Resolution:
Rationale:  Efficiency of tearing down an application can occur by cutting down on the number of calls needed for application teardown behavior. The application component's releaseObject operation can perform the behavior of disconnecting ports thus eliminating these calls to the component for each port being disconnected. Only the Services ports need to be disconnected from application components.
1.	Section 8.3.4.2.3.1 ApplicationManager semantics section - disconnect non-application component providers ports.

The plan is for the SCA to be modified to reflect a new AEP that is applicable for smaller footpring operating systems. This specification should incorporate the revised LwAEP in addition to the existing AEP. A copy of the proprosed revision can be obtained from the SCA CP site or from the submitter

Resolution:
Rationale:  For more constraint systems like a DSP versus a GPP, add a lighter weight POSIX profile. This profile definition should map to the functionality commonly supported by DSP Operating Systems.
1.	Annex H, mainly adding LwAEP column to all tables.

Fig. 9-57 shows IPriorityFlowControl as a specialization of
IFlowControlManagement. The IDL implements Fig. 9-57. However, Fig. 9-60
shows IPriorityFlowControl as a specialization of
IFlowControlSignalling.
Because Fig. 9-60 models the Protocol Data Unit Facilities, modifying
this
inconsistency will change the interface definition of IPriorityPdu,
which
is shown as a specialization of IPriorityFlowControl and IBasePdu.


Resolution: I'm not sure.


I found this inconsistency while resolving issues related to Issue 8296.
Should I still post a resolution for Issue 8296?

Resolution:
Remove specialization of FlowControlSignaling from PriorityFlowControl as shown in PDU Facilities Overview figure.

Section 8.1.6.1.2 ExecutableDevice, Semantics
Remove the requirement of returning a minus one when the process or thread
is not created since the following requirement  raises an exception.
"The execute operation shall raise the ExecuteFail exception when the
operating system “execute” function for the device is not successful."


From
"The execute operation returns a unique processID for the process or thread
that it created, or a processID of minus 1 (-1) when a process/thread is
not created."


To
"The execute operation returns a unique processID for the process or thread
that it created."

Resolution:
1.	Update text in Section 8.1.6.1.2 ExecutableDevice, Semantics

Problem: ProcessIDType is Ulong which does not match POSIX definition and
also consistent with SCA CP recommendation


Change ProcessIDType from Ulong to Long for ExecutableDevice interface
definition

Resolution:
1.	Change type for ProcessIDType to be a Long in Section 8.1.6.1.2 ExecutableDevice, Types and Exceptions.
2.	Update Annex A.4 CF Device Interfaces by changing ProcessIDType to be a long instead unsigned long.
3.	Update CFDevices.idl machine file by changing ProcessIDType to be a long instead unsigned long.
4.	Update the Rose Model for ExecutabeDevice interface by changing ProcessIDType to be a long instead unsigned long.

1.  The specification text and UML Model for
DeviceManagerRegistration::registerService () operation
registeringService parameter type use the ServiceComponent stereotype,
whereas the PSM and the IDL use the type Object.  A more descriptive
type should be used for the PSM and the IDL.


2.  DeviceManagerRegistration::registerService () operation
unregisteringService parameter type:
The specification text synopsis uses the type Service.  The UML Model
uses the type ServiceComponent.  The PSM and the IDL use the type
Object.  These types should logically match.


3.  The DeviceManagerRegistration registerDeviceManager () and
unregisterDeviceManager () operations texts refer to addition and
removal of the DeviceManager's Service(s) to/from the domain.  Instead,
they should refer to ServiceComponent(s).


4.  The DeviceManagerRegistration registerService () and
unregisterService () operations text refer to
registration/addition/unregistration/removal of Service(s) to/from the
domain.  Instead, they should refer to ServiceComponent(s).



Proposed Solution:


1.  The PSM and the IDL should use the Service typedef defined in
CFBaseTypes.idl as the registeringService/unregisteringService parameter
types for DeviceManagerRegistration::registerService
()/unregisterService ().


2.  The unregisteringService parameter type for the
DeviceManagerRegistration::unregisterService () operation should be
ServiceComponent.


3.  Refer to registration/unregistration of ServiceComponent(s), instead
of Service(s), in the DeviceManagerRegistration registerDeviceManager ()
and unregisterDeviceManager () operations.


4.  Refer to registration/addition/unregistration/removal of
ServiceComponent(s), instead of Service(s), in the
DeviceManagerRegistration registerService () and unregisterService ()
operations.


5.  The UML Model should use the ServiceComponent type instead of
SWRadioService for the registeringService/unregisteringService
parameters of the DeviceManager ServiceRegistration interface's
registerService/unregisterService operations.



Rationale:  Correctness and clarity of types used, in the correct
context for the specification text, the UML Model, the PSM and the IDL.

I am looking at the IDL found in ftp://ftp.omg.org/pub/swradio-ftf/specification/2nd%20FTF/convenience/IDL. I notice that the files DfSWRadioMeasurementManagement.idl, DfSWRadioMeasurementPoint.idl, and DfSWRadioMeasurementTypes.idl fail to compile because they expect CFCommonTypes.idl to contain a definition for "TimeType". 

I did not find TimeType defined in the SCA IDL, but I did find the following definition in the SCA LogService.idl file: 
                struct LogTimeType { 
                        /* This value corresponds to POSIX time_t type */ 
                        long seconds; 
                        long nanoseconds; 
                }; 


Instead of using a definition like the one above I would recommend using TimeBase::TimeT. This would make it more compatible with the CORBA Time service. My recommendation is to add the following line to the CFCommonTypes.idl file: 
             typedef TimeBase::TimeT TimeType; 

Resolution:
The specification IDL is correct. Make the machine IDL for CFCommonTypes agree with specification.
Also remove the include statement of "DfSWRadioCommonLayerBasicTypes.idl" from the Measurement Module interfaces.

It appears the file DfSWRadioErrorControlManagement.idl has an error with scoping rules. It has interface ErrorControl directly nested inside module ErrorControl. My copy of the CommonObject Request Broker Architecture: CoreSpecification section 3.20.2 indicates that is not allowed. This file was rejected by the TAO IDL compiler version 1.4.7. 

Likewise  the file DfSWRadioMeasurementTypes.idl has struct Measurement inside module Measurement. The files DfSWRadioMeasurementStorage.idl and DfSWRadioMeasurementRecorder.idl depend on DfSWRadioMeasurementTypes.idl, so if we rename the struct to something like MeasurementS we would have to modify the other files too. 

Once I modified these files and added TimeType to CFCommonTypes.idl I successfully compiled all files with the TAO IDL compiler. 

Resolution:
Make the machine IDL files agree with specification. These changes have already been made in the specification. The IDL files are out of date.