Issues for 2nd PIM & PSM For Software Radio Revision Task Force

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

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

Issue 8988: Invalid ServiceProperty’s capabilityModel attribute Type
Issue 9229: Flexibility to Perform Allocation, Load and Execute Behavior
Issue 9231: Inconsistent use of the term "Facility or Facilities"
Issue 9297: Exception Definition Missing
Issue 9298: PropertyValue Definition Incomplete
Issue 9299: Object Type Not Defined.
Issue 9300: Wrong Stereotypes for Property Types
Issue 9301: Port Not Defined
Issue 9302: FileSystemComponent Constraint Missing
Issue 9303: LoadType Inconsistent
Issue 9304: Add CharacteristicSelectionType Type Constraint
Issue 9305: LoadableDeviceComponent CharacteristicSetProperties Definition Incomplete
Issue 9306: ConfigureProperty Errors
Issue 9307: Missing type for loadKind property for loadabledevicecomponent
Issue 9308: Constant Interface Definitions Invalid
Issue 9313: Application Stereotype Incomplete
Issue 9314: Code Artifact Manifest Constraint Missing
Issue 9315: ExecutableCode Constraint Missing
Issue 9316: Make Descriptor and LoadableCode a parent of File.
Issue 9317: Add other Descriptor Types
Issue 9331: Add Required and Provided ports definitions that are specialization of SWRa
Issue 9332: SAD FindComponent Cardinality Error
Issue 9333: Add SAD CollocationProcess Element.
Issue 9334: SAD ComponentInstantiation Description Error
Issue 9335: L.2.1 Software Package Desription
Issue 9336: ServiceComponent Definition Issue
Issue 9346: ApplicationResourceComponent Definition
Issue 9347: SWRadioComponent additional constraint
Issue 9348: Oneway operation stereotype
Issue 9349: Simple Property Datatype
Issue 9350: AntennaElement
Issue 9469: PIM and PSM SWRadio Spec Figures Issue
Issue 9581: PTT Signal De-Assertion
Issue 9582: Waveform Response to Audio Device RTS Signal
Issue 9583: ConcreteDataPdu: New Attributes
Issue 9584: Stream / Channel - Parameters
Issue 9585: SCA 2.2.x Backward Compatability
Issue 9610: DeviceManager Created Components Should Not Be Constrained
Issue 9612: Issue with Component Framework Spec
Issue 9616: POSIX Profile Reference
Issue 9909: Physical and IO facilities Location Issue
Issue 9910: TestableObject Interface Runtest Operation Issue
Issue 9916: Consistent PIM Interface Name Issue
Issue 9918: MAC Typo Issue
Issue 9919: Missing Acknowledgements in SWRadio Spec
Issue 9924: swradio Issue - Common and Data Link Layer Facilities
Issue 9927: swradio Reference Section Issue
Issue 10414: Unregister Operation Issues
Issue 10415: Application Deployment Attributes
Issue 10416: Enumeration Issues
Issue 10417: PIM and PSM for Radio Software Components
Issue 10418: New Install Application Exception
Issue 10419: Domain Register Operation Issues
Issue 10420: Section H; evaluate error conditions
Issue 10421: LW Resource and Device Components
Issue 10424: Stereotypes Tables Inconsistencies
Issue 10425: Artifact Issues
Issue 10588: Erroneous reference in PIM & PSM for SW Radio dtc/06-04-18
Issue 10638: DTD XML Relationships Oversight
Issue 11242: issue in section 7.1.4 of SWRadio Component Framework Spec (formal/07-03-04
Issue 11418: Definition of Complex type
Issue 13932: Implementation Properties

Issue 8988: Invalid ServiceProperty’s capabilityModel attribute Type (swradio-rtf)

The ServiceProperty’s capabilityModel attribute in the text has a type of Boolean instead of String. The diagram is correct.

 

Solution:

 

8.1.3.12 ServiceProperty

Attributes noheader section

 

From

“capabilityModel: Boolean”

 

 

To

“capabilityModel: String”

Resolution:
Make ServiceProperty's capabilityModel attribute type a string. 

Flexibility to Perform Allocation, Load and Execute Behavior at
Component as well as Device Level


Problem:  For software radio deployment, the ability to perform capacity
allocation/deallocation, object module load/unload, and process/thread
execution/termination should not be restricted to devices.  Flexibility
should be provided such that for an application component, it would be
possible for such behavior to be managed by the ApplicationFactory at
the component level, without the constraint of having to use a device.


Proposed Solution:  Operations load () and unload (), execute () and
terminate (), and allocate () and deallocate () in addition to all
related types and behavior should be broken out of the Device,
LoadableDevice and ExecutableDevice interfaces, each put into their own
separate interfaces (e.g.  LoadableInterface, ExecutableInterface,
AllocableInterface), used (not inherited) from the Device,
LoadableDevice and ExecutableDevice interfaces, and then used optionally
by the ApplicationFactory for deployment of components that have load,
execute or capacity behavior and do not need a device for deployment.  


Rationale:  Need for flexibility in the SWRADIO UML Profile to
accommodate deployment of an application component with or without a
device.

Resolution:
Make new interface called CapacityManager that is basically the same definition as Device but without the specialization relationship and attributes. Move InvalidState exception definition at the package level instead at the interface level since other interfaces will need it.
Have the LoadableDevice be a specialization of Device and Loadable interfaces.
Make new interface called Loadable that is basically the same definition as LoadableDevice but without the specialization relationship.
Have the LoadableDevice be a specialization of Device and Loadable interfaces.
Make new interface called Executable that is basically the same definition of ExecutableDevice but without the specialization relationship.
Have the ExecutableDevice be a specialization of LoadableDevice and Executable interfaces.

Problem: In chapter 4, Facility is defined to be, "An environment providing
a realization of certain functionality through set of well defined
interfaces." Subsequently, in chapter 9, the SWRADIO PIM components (5
Facilities) are defined not referring to "environments", but refer to "set
of interfaces", "set of services", and for the last three, functional
definitions. These "facility" definitions are confusing, and need to be
worded to reflect consistent ideas.


Proposed Solution: The ultimate solution would be to refactor the
specification to reflect the standard definitions provided in the OMAG
(http://www.omg.org/docs/ab/97-05-05.pdf <http://www.omg.org/oma/>) - upon
which the MDA (<http://www.omg.org/docs/omg/03-06-01.pdf> and its current
terminologies) was guided. Shy of that, redo the definitions of "facility"
in chapter 4, and change the facilities as defined in chapter 9 to
consistently reflect the following definitions.


In summary there are four classifications of object interfaces:


*       Object Services are interfaces for general services that are likely
to be used in any program based on distributed objects.
*       Common Facilities are interfaces for horizontal end-user-oriented
facilities applicable to most application domains.
*       Domain Interfaces are application domain-specific interfaces.
*       Application Interfaces are non-standardized application-specific
interfaces.


Rationale: This change will clarify the intent of a facility in the SWRadio
specification, and make it consistent with standard OMG-speak.

Resolution:
1.	Remove the word "environment" from the definition of facility
2.	Refine the definitions of the five facilities to be more consistent in their use of terms like "interfaces", "services", and "defines <…> functionality".

Exception Definition Missing. Types in the profile that are stereotype as exception is currently in valid do to exception metaclass/type being removed from UML 2.0. Need to define exception stereotype so can use that in defining the exception types in the profile. Add definition to Interface and Port Stereotypes section. Extension of classifier or Datatype

Resolution:
Need to define exception stereotype so one can use that in defining the exception types in the profile. Add definition to Interface and Port Stereotypes section. Exception is an extension of UML Classifier.

PropertyValue Definition Incomplete. A type is needed to complete the PropertyValue type definition.  In order to define the propertyvalue type, add an “any” data type for type for the PropertyValue Value attribute and define this type in the Base Types section. Applied Stereotypes as a dataType. 

Resolution:
In order to define the PropertyValue value attribute, add an "Any" datatype for type for the PropertyValue value attribute and then define this type in the Base Types section. Applied Stereotype for Any is a UML dataType.

Object Type Not Defined. Object type not defined in PortConnection IF for the connection operation. Add Object type in the Base Types section. 

Resolution:
Add Object type in the Base Types section.  Applied Stereotype for Object is a UML class.

Wrong Stereotypes for Property Types. Make struct property and test def property types stereotypes of datatype instead of class in the properties. These should be treated type definitions not classes. EnumerationProperty?

Port Not Defined. Port type not defined in PortType definition for PortSupplier IF. Add Port type to Base Types section and make it a specialization of Object type

Resolution:
Change definition of PortType, use Object instead of Port.

FileSystemComponent Constraint Missing. Missing FileSystem interface constraint for FileSystemComponent. Add constraint to FileSystemComponent definition as was done for other FileServices components.

Resolution:
Add constraint to FileSystemComponent definition as was done for other FileServices components. 

LoadType Inconsistent. The LoadType definition is inconsistent with text. Make the definition agree with text

Resolution:
Make the definition agree with text by adding "SHARED_LIBRARY enumeration literal to definition. 

Add CharacteristicSelectionType Type Constraint. CharacteristicSelectionType needs another constraint for the type to be restricted to an enumeration type. 

Discussion:
This constraint is not necessary since the constraint is already stated for SimpleProperty, which CharacteristicSelectionType is a specialization of. Jerry agrees to withdraw the issue.
Disposition:	Closed, no change

LoadableDeviceComponent CharacteristicSetProperties Definition Incomplete. Define a NameVersionCharacteristic datatype of applied stereotype of StuctProperty Type with two attributes name and version. Add new type to base types section. Use this new type for characteristicset properties for loadabledevicecomponent. Also change descriptions of these characteristics properties by removing “characteristic [1] = ( qualifier [1] = ( name ="Name", value = ""), qualifier [2] = ( name ="Version", value = "")))” from description with NameVersionCharacteristic type

Resolution:
Add a NameVersionCharacteristic datatype of applied stereotype of StuctProperty type with two attributes name and version of string type. Add this new type to Base Types section. Use this new type for characteristicsetproperty library, os, and runtime definitions for loadabledevicecomponent. Also change descriptions of these characteristics properties by removing "characteristic [1] = ( qualifier [1] = ( name ="Name", value = ""), qualifier [2] = ( name ="Version", value = "")))" from description with NameVersionCharacteristic type. 

ConfigureProperty Errors. Configure property needs to be a type of radio property and type constraint is missing (see QueryProperty constraint). 

Resolution:
Make ConfigureProperty a type of RadioProperty. Add QueryProperty constraint also for ConfigureProperty definition.

Missing type for loadKind property for loadabledevicecomponent. In loadKind attribute text replace “(name = "Load Kind", type = string)” with LoadType [1..*].

Resolution:
In loadKind attribute text replace "(name = "Load Kind", type = string)" with LoadType [1..*]. 

Define a constant property to clearly show the intent of property. Add a Constant property stereotype definition to the interface and Port Stereotypes.

Move the constant defs type sections in executabledevice and filesystem interface to attributes section and use stereotype constant for them. Add transformation rule too to section 10 PSM.

Resolution:
Add a Constant property stereotype definition to the interface and Port Stereotypes.
Move the constant defs type sections in executabledevice and filesystem interface to attributes section and use stereotype constant for them. Add transformation rule too to section 10 PSM. Note for the break out specs section 10 is probably section 9. 

Application component definition is lacking details, some of them being as follows:

1. Missing Constraints

Need to realize the Resource interface 
Need at least one componentinstantiation part that is a ResourceComponent and is an assembly controller. 
2. Add ComponentInstantiation stereotype definition, an extension of Part.

Resolution:
Add constraints to Application.
Add componentinstantiation stereotype an extension of Property.
Add serviceconnector stereotype an entension of connector.
Add servicecomponentinstantiation stereotype an extension of Property.

Add two subsections for 7.1.7, Application Components Types and Application Components Stereotypes

Add constraint for the type of component manifested for by Executable code artifacts.

ServiceExecutableCode manifest a ServiceComponent

ResourceExecutableCode manifest a ResourceComponent and/or ResourceFactoryComponents

LogicalDeviceExecutableCode manifest a DeviceComponent type.

Resolution:
ServiceExecutableCode shall manifest a ServiceComponent
ResourceExecutableCode shall manifest a ResourceComponent and/or ResourceFactoryComponents
LogicalDeviceExecutableCode shall manifest a DeviceComponent type.

For ExecutableCode add a constraint on properties being executableproperty types

Resolution:
For ExecutableCode add a constraint on properties being executableproperty types.

Resolution:
Replace N/A in table with File. 

Add other Descriptor Types that are specialization of Descriptor, such as PropertiesDescriptor, SoftwareComponentDescriptor, SoftwarePkgDescriptor, SoftwareAssemblyDescriptor, DeviceConfigurationDescriptor, DeviceDescriptor, and DomainManagerDescriptor

Resolution:
Add other Descriptor types that are specialization of Descriptor, such as PropertiesDescriptor, SoftwareComponentDescriptor, SoftwarePkgDescriptor, SoftwareAssemblyDescriptor, DeviceConfigurationDescriptor, DeviceDescriptor, and DomainManagerDescriptor. 

Add Required and Provided ports definitions that are specialization of SWRadioPort.   The required port should have a tag value that indicates a connection threshold of unsigned short. A ProvidedPort provides a service only, therefore its constraint is service is true. A RequiredPort requires a service, its constraint is service is false. Also the required and provided ports should have a constraint of one interface type, not multiple different interface types. This constraint could be stated at the SWRadioPort level. This allows an application definition to be formed that clearly shows the direction on the connections between the application’s parts.

Resolution:
Add Requires and Provides ports definitions that are specialization of SWRadioPort. Requires port should have a tag value that indicates a connection threshold of unsigned short. A ProvidesPort provides a service only, therefore its constraint is service is true. A RequiresPort requires a service, its constraint is service is false. Also requires and provides ports should have a constraint of one interface type, not multiple different interface types. This constraint should be stated at the SWRadioPort level

For the componentinstantiation element the findcomponent cardinality cannot be optional

Discussion:
This is not an error, needs to be optional for non-CORBA component solutions. Jerry agrees to withdraw the issue.
Disposition:	Closed, no change

Need to add an optional collocation process element in order to express componentinstantiations that are process collocated. This behavior goes with ExecutableDevic::execute behavior

Resolution:
Add an optional processcollocation element to the partitioning and hostcollocation element definitions. 

Section L.6.3.1.2.  The description for the component properties is not right for “execparam” types. Section L.6.3.1.2 text should be replaced as follows:

“L.6.3.1.2 componentinstantiation.

The componentinstantiation element (see Figure L-108) is intended to describe a particular instantiation of a component relative to a componentplacement element. The componentinstantiation’s id attribute uniquely identifies the component. The componentinstantiation element’s id may be referenced by the usesport and providesport

elements within the SAD file. It is the component name for the instantiation not the application name. The optional componentproperties element (see Figure L-109) is a list of configure, factoryparam, and/or execparam properties values that are used in creating the component or for the initial configuration of the component. The componentproperty definitions as stated in the corresponding SCD. 

 

The following sources will be searched in the given precedence order for initial values for “configure” kind of properties, whose modes are “readwrite” or “writeonly” and "execparam" kind of properties:

1.         The componentproperties element of the componentinstantiation element in SAD. 

 

The following sources will be searched initial values for the “factoryparam” kind of properties in the given precedence

order:

1. The componentinstantiation element’s findcomponent element’s componentresourcefactoryref

element’s resourcefactoryproperties element in the SAD

 

The findcomponent element (see Figure L-110) is used to obtain the object reference for the component instance. The two sources for obtaining an object reference are:

1. The componentresourcefactoryref element, which refers to a particular ResourceFactoryComponent componentinstantiation element found in the SAD, which is used to obtain a ResourceComponent instance for this componentinstantiation element. The refid attribute refers to a unique componentinstantiation id attribute. The componentresourcefactoryref element contains an optional resourcefactoryproperties element (see Figure L-111), which specifies the properties “qualifiers”, for

the ResourceFactoryComponent create call.

2. The optional findcomponent element should be specified except when there is no object reference for the component instance (e.g., FPGA code). The CORBA Naming Service, which is used to find the component’s object reference. The name specified in the namingservice element is a partial name that is used by the ApplicationFactoryComponent to form the complete context name.”

Resolution:
Reword the L.6.3.1.2 componentinstantiation to correct errors on searching for properties and remove the sentence "It is the component name for the instantiation not the application name." since the sentence is confusing on what is meant or intended.

Reword the following sentence in section from “ExecutableProperty(s) are usually only defined at the SDP-level and implementation level.” to “ExecutableProperty(s) are used for component construction”

Resolution:
Reword the following sentence in section from "ExecutableProperty(s) are usually only defined at the SDP-level and implementation level." to "ExecutableProperty(s) are used for component construction by a component's main process."

Make ServiceComponent non-abstract type and remove type definitions from stereotype definition. Stereotype can be used to stereotype a service such as naming, event, and log.

Resolution:
Make ServiceComponent non-abstract type and remove type definitions from stereotype definition

ApplicationResourceComponent Definition. ApplicationResourceComponent needs to a specialization of ResourceComponent

Resolution:
Change ApplicationResourceComponent description to include that the component is a specialization of ResourceComponent. 

SWRadioComponent additional constraint. SWRadioComponent needs a constraint that when connected to a log service, the ProducerLOGLevel property shall be supported

Resolution:
Add requirement that the SWRadioComponent shall support the ProducerLogLevel when the component is connected to a log service. 

Oneway operation stereotype. Oneway operation stereotype used in swradio facilities is not defined in profile. Add definition to Interfaces and Ports stereotypes in profile.

Resolution:
Add oneway stereotype to 7.1.3 Interface and Port Stereotypes

Simple Property Datatype. This allows users to form common definitions that can be used for components properties. A data/primitive stereotype that similar tags as RadioProperty. Add to properties section.

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

AntennaElement. AntennaElement not in Communication Equipment Stereotype table

Resolution:
Add AntennaElement to Communication Equipment Stereotype table.

There are few figures in the specification that are missing and a few figures that are displaying visibility information should be suppressed for the M1 illustrations.

 

Resolution:

Fixed Figures: 

Figure 7.7 - ResourceFactoryComponent M1 Illustration 
Figure 7.12 - ExecutableDeviceComponent M1 Illustration 
Figure 7.13 - LoadableDeviceComponent M1 Illustration 
Remove Figure 7.39 - ApplicationFactory Capacity Overview

Add Figure Figure 7.38 - Application Definition

Add Figure 7.40 and title for 7.40

Add title to Figure 7.42

Resolution:
Fixed Figures: 
§	Figure 8.7 - ResourceFactoryComponent M1 Illustration
§	Figure 8.12 - ExecutableDeviceComponent M1 Illustration
§	Figure 8.13 - LoadableDeviceComponent M1 Illustration
Remove Figure 8.39 - ApplicationFactory Capacity Overview
Add Figure Figure 8.38 - Application Definition
Add Figure 8.40 and title for 8.40
Figure 8.42 no title
7.2.2.1.1.1 DomainEventChannels, 7.2.2.1.1.2 DomainInstallation, and 7.2.2.1.1.3 DeviceManagerRegistration reference wrong figure. Needs to be Figure 7.28

The following issue was raised in the SDR Forum's SCA WG:


The PTTSignal interface provides a mechanism to assert the PTT signal, but
we cannot find the mechanism to de-assert the PTT when the transmission is
complete. The SDRF believes it is important to have the ability to de-assert
the PTT signal. This could be accomplished by adding a Boolean parameter to
the function or be adding a second function.

Discussion:
A waveform component would implement a provides PTTSignalInPort. PTTSignal derives from IOSignal (see section 9.4.3). IOSignal supports the operation:

signalRTS (in rts: Boolean)

The audio component that interfaces with the PTT events from the device would implement a required PTTSignalOutPort. When the PTT is engaged, signalRTS would send a True. When it is released it would send a False. The waveform component would interpret the rts accordingly to determine the assert or de-assert condition.

As such, the issue will be closed with no action. Advise the SDR Forum of the procedure.
Disposition:	Closed, no change

The following issue was raised in the SDR Forum's SCA WG:


The PTT function is a oneway call and the audio device does not wait for an
RTS signal. This situation prevents the waveform from providing a negative
response to the PTT. If the waveform is unable to transmit data at the time
of a PTT, does the waveform just ignore/drop the data without alerting the
audio device or user through some specified mechanism?

Discussion:
This issue is deferred to the follow-on RTF, since RTF #1 ran out of time.  
Current rational is that a RTS management is a function of the waveform as opposed to the audio device. A specialization to support this could be done. Further discussion with the SDR Forum is needed to fully understand the requirements.
Disposition:	Deferred

The following issue was raised in the SDR Forum's SCA WG:


The group was concerned that without a control structure along with the data
payload, the Audio API might impose unnecessary constraints. Discussion
within the group identified that a control structure containing at least a
Stream Id, a Payload Length, and a Sequence number could provide much
greater flexibility that the API as currently stated

Discussion:
This issue is deferred to the follow-on RTF, since RTF #1 ran out of time.  
Payload Length is built into the OctetSequence (delegate this problem to the PSM). The other two parameters would need the SimplePDU to instantiate it to conform to what is needed (this could include payload length as well). SimplePDU is a basic building block. It is unclear however how pervasive the use of these parameters are. If all audio devices need this data then these data could be supported. If a subset of devices would use this information, then specialize it. Further discussion with the SDR Forum is needed to fully understand the requirements.
Disposition:	Deferred

The following issue was raised in the SDR Forum's SCA WG:


The Audio API does not include an interface for configuring or exchanging
information that is specific to a stream or channel. Such information might
include: quality of service parameters, packet size, symbol size, priority,
and audio codec.

Discussion:
This issue is deferred to the follow-on RTF, since RTF #1 ran out of time.  
Further discussion with the SDR Forum is needed to fully understand the requirements (more complete set and the use cases under which they are used). 
Disposition:	Deferred

SDRF, NASA, JPEO have all indicated that the probabilty of broader adoption
of the PIM/PSM For Software Radio Components would be greater if it were
fully backward compatible with the SCA 2.2.x specifications.


This issue simply stated is to request that the PIM/PSM be modified such
that it, as a framework deployed and running, can run any SCA 2.2.x waveform
or application without modification, to the full extent it can run on a SCA
2.2.x framework.

Discussion:
Backward compatibility is a large topic. To respond to this it will be necessary to issue an RFI to more completely collect requirements. A couple approaches could be:
1.	Build in backward compatibility (per specified requirements)
2.	Inasmuch as there is little or no definition of backward compatibility within the SCA itself, that the JTRS CP process be used by industry to address a convergence of JTRS Increment 2 and P2SRC technologies, particularly given the matching vision of both the SCA and the MDA (interoperability, portability, reusability). Therefore the RTF will develop an RFI and send it out.
Disposition:	Closed, no change

SWRADIO RTF Issue - DeviceManager Created Components Should Not Be Constrained to be Resource Components                                                                                                                         The DeviceManager should have ApplicationFactory's flexibility in
creating components, such that the components it creates would not have
to have the full capability of being initializable, configurable, etc..
That is, DeviceManager created components should not have to be full
blown Resource Components.


Rationale:  
Flexibility in the type of components created by a DeviceManager.

Discussion:
No longer an issue.  This flexibility is already in DeviceManagerComponent Semantics. Text from Spec "The DeviceManagerComponent shall initialize and configure ServiceComponents that are started by the DeviceManagerComponent after they have registered with the DeviceManagerComponent provided they realize the Lifecycle and PropertySet interfaces. The DeviceManagerComponent shall configure a registered Service, provided the registered Service has ConfigureProperty(s)."
Disposition:	Closed, no change

Issue with Component Framework Spec, section 7.2.3.2.2 Application Factory and section 7.2.3.2.4 ApplicationFactoryComponent

This section discusses the creation of a specific type of Application in the SWRadio domain.  The wording of the section uses the terminology such as 'the Application' and 'an Application'.  As I read the section, I was struck with a sense of singularity.  I think the idea that the factory is used to build 'instances of Applications of a specific type' is lost.  The factory can be used to build more than one instance at a time.  

Recommendation: Update section(s) to highlight instance creation while still capturing all the behavior associated with the creation of each instance.

Rationale: Concept of the factory and its use to create multiple instances of the application in the domain is a powerful concept and should not be lost or confused.

Resolution:
Change descriptions and semantics for ApplicationFactory, ApplicationManager, and ApplicationFactoryComponent to indicate multiple instances behavior. Also fix the ApplicationManager and ApplicationFactoryComponent M1 figures along with associations. Add a constraint for the ApplicationFactoryComponent.

The POSIX profile is based upon the 1998 standard. 

Standardized Application Environment Profile - POSIX® Realtime Application Support (AEP), IEEE Std 1003.13-1998 Institute of Electrical and Electronics Engineers, 1998

 

Resolution

Update the reference and profiles to be based upon the latest standard (PSE52:2003)

Resolution:
Update the reference and profiles to be based upon the latest standard (PSE52:2003). Two items to pay close attention to are that POSIX_MATH operations are not incorporated into the LwAEP and many of the POSIX_MATH float operations are not included in the regular AEP, these are  subject to revision based on the vote results.

PIM and PSM Software Radio Spec

 

Issue: With the breakup of the specification into multiple volumes and to be consistent with the other volumes, the physical and I/O layer facilities should be located with the communication channel profile. 

 

Resolution: Move the I/O and physical layer facilities to the comm. Channel volume spec. Rename Data link and physical layer facilities spec to Common land Data Link layer facilities. Also consider renaming interfaces packages in component framework profile and spec volume to be facilities to be consistent with other profiles and volumes.

Resolution:
Move the I/O and physical layer facilities to the comm. 
Channel volume spec. Rename Data link and physical layer facilities spec to Common and Data Link layer facilities. Also consider renaming interfaces packages in component framework profile and spec volume to be facilities to be consistent with other profiles and volumes.

PIM and PSM for Software Radio Components Spec

 

Issue: TestableObject interface, runtest operation, takes in a string type for test id which is not efficient for processing and is not backwards compatible with sca. 

 

Resolution: change the testableobject interface runTest operation to take in an integer test id instead of string. Add an optional label attribute for the test property xml definition.

Resolution:
Change TestableObject::runtest testId string to unsigned long and change Property integerId property to ID.

Issue: Issue 7661 were not totally done as stated in the resolution of changing the interface names  by removing the prefix “I” from the name in the SWRadio Facilities when updated with the interface stereotypes. The rest of the specification was done correctly.

 

Resolution: remove the prefix “I” in the interface names in the SWRadio PIM Facilities. This change mainly effects the Common Layer, Data Link and Physical Layer facilities. The CORBA interfaces do not have I in the Name.

 

OMG Issue No:  7661

Title:   Lack Consistent use of SWRadio Stereotypes in Facilities interface

Source:

Raytheon, Mr. Gerald Lee Bickle, Gerald_L_Bickle@raytheon.com

Summary:

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.

Resolution:

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

 

Resolution:
Remove the prefix "I" in the interface names in the SWRadio PIM Facilities. This change mainly effects the Common Layer, Data Link and Physical Layer facilities. The CORBA interfaces do not have I in the Name. This also means the figures will need to be updated.
This change needs to be coordinated with Issue 9909.

Issue: MAC throughout the spec is stated to be medium access control instead of media access control.

http://webopedia.internet.com/quick_ref/OSI_Layers.asp

 

Resolution: change medium access control to media access control through software spec where used.

 

Discussion:
Eyermann, Phil - ACD [Phil.Eyermann@itt.com]: "While one or the other is probably "correct", both are used by the networking community.  Since devices are connected to a single medium at a time, I lean towards the current "medium"."
From Manfred R. Koethe [koethe@88solutions.com]: "I would recommend to stay with "Medium", which is the official language of ISO-OSI and IEEE 802. [And ISO-OSI coined this term...]
For example:
ISO/IEC 10039, Information technology - Open systems interconnection - Local area networks - Medium Access Control (MAC) service definition"
Disposition:	Closed, no change

PIM and PSM for SW Radio Components

 

Issue: Not all the copyright names appear in the acknowledgement list.

 

Resolution: Add the missing names (Northrop Grumman, OMG, David Frankel) to the acknowledgement list.

Resolution:
Add copyright names to acknowledgement list

PIM and PSM for Software Radio Components, Common and Data Link Layer Facilities

 

Issue: There are number of inconsistencies in the Common and Data Link Layer Facilities, some of the inconsistencies are as follows:

Duplicated Type Definitions 
Types not defined 
Associations for Measurement Interfaces 
Inconsistencies between figure and text 
flow control singalling interface typo 
transitDelay : Double inconsistent, needs to be TimeType. 
 

Resolution: Some of the changes are as follows:

1. Eliminate Duplicate Type definitions, 

2.make figure and text agree, 

3. remove associations from measurement figure and text, and add semantics for measurements where needed, 

4. rename FlowControlSignalling to FlowControlSignaling

5. Add missing types, InfoType, etc.

6. Make TransitDelay a TimeType.

Resolution:
Some of the changes are as follows:
1. Eliminate Duplicate Type definitions, 
2. Make figure and text agree, 
3. Remove associations from measurement figure and text, and add semantics for measurements where needed, 
4. Rename FlowControlSignalling to FlowControlSignaling
5. Add missing types, InfoType, etc.
6. Make TransitDelay a TimeType.

Issue: Fix the normative and non-normative references in the specification including the new volume specifications.

 

Resolution: The OMG DTC numbers will be added to the normative and non-normative references. XMI files will be placed in the normative references. Verify all normative references are normative sources, if not move to non-normative references section. Add any missing references to the normative and non-normative sections.

Resolution:
The OMG DTC numbers will be added to the normative and non-normative references. XMI files will be placed in the normative references. Verify all normative references are normative sources, if not move to non-normative references section. Add any missing references to the normative and non-normative sections.

Problem

The domain manager and device manager unregister operations take in an object reference, which cannot be used directly for determining what component to unregister since one cannot compare on object references, so a callback is needed to get the identifier for unregistering service thus being inefficient.

 

Proposed Solution: Replace the unregistering operations and remove device parameters with an unregistering identifier parameter of string type. This change affects CompositeDevice, DeviceManagerRegistration and ServiceRegistration interfaces.

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

Issue: The Application Component Deployment Attributes are usually not needed in a fielded system, therefore make these attributes optional. 

Proposed Solution: Break the Application attributes out into a separate interface that can be provided by CF Application Component implementation.

Resolution:
Break the Application deployment attributes out into a separate interface that can be provided by CF ApplicationManager Component implementation.

Problem: Not clear that the enumeration types are configurable and queryable properties.

 

Proposed Solution: For Configure and Query Property definitions add valid type clarification in the constraints definition for EnumerationProperty. Also change the XML PSM to agree with definition as appropriate

Resolution:
For Configure and Query Property definitions add valid type clarification in the constraints definition for EnumerationProperty. 

Also change the XML PSM to agree with definition as appropriate. Add enumerations to simplesequence element in Properties DTD to agree profile definition.

Issues:

 

Device Manager Interface, ServiceSequence type is undefined for registeredSerices attribute 
DeviceManagerRegistration Interface, Parameter type is DeviceManager interface needs to be changed to DeviceManagerComponent. 
Device Management Interfaces description, has SWRadio’s in description. This was suppose to taken out by a previous issue resolution. 
Remove <<optional>> from spec, not defined. 
The PIM facilities references in PhysicalLayerResource, LinkLayerControlresource, and MediumAccessControlResource is unclear 
The PropertyValue constraint needs to also state primitive sequence types. 
Add clarification statement to characteristicSelectionProperty description for better understanding. 
StreamPort is missing constraints section to agree with Interface & Port Stereotypes table. 
 

Proposed Resolution

 

For DeviceManager interface, define ServiceSequence to be an association of many ServiceTypes. 
DeviceManagerRegistration Interface, change parameter type of DeviceManger interface to DeviceManagerComponent. 
Device Management Interfaces description, replace SWRadio’s node with node’s 
Remove <<optional>> from spec 
The PIM facilities references in PhysicalLayerResource, LinkLayerControlresource, and MediumAccessControlResource should reference the Common and Data Link Layer Facilities and/or Communication Channel volume specs. 
Add to PropertyValue’s constraint definition - primitive sequence types. 
Add clarification statement to the end of characteristicSelectionProperty description. 
Add constraint section to StreamPort as stated in Interface & Port Stereotypes table table. 

Resolution:
1.	For DeviceManager interface, define ServiceSequence to be an association of many ServiceTypes. 
2.	DeviceManagerRegistration Interface, change parameter type of DeviceManger interface to DeviceManagerComponent. 
3.	Device Management Interfaces description, replace SWRadio's node with node's 
4.	Remove <<optional>> from spec 
5.	The PIM facilities references in PhysicalLayerResource, LinkLayerControlresource, and MediumAccessControlResource should reference the Common and Data Link Layer Facilities and/or Communication Channel volume specs. 
6.	Add to PropertyValue's constraint definition - primitive sequence types. 
7.	Add clarification statement to the end of characteristicSelectionProperty description. 
8.	Add constraint section to StreamPort as stated in Interface & Port Stereotypes table.

Issue: The SCA added a new exception for the installApplication operation. The exception indicates the behavior for already installed application.

 

Proposed Resolution:

Add a new exception called ApplicationAlreadyInstalled that is given out when an application has already been installed.

Resolution:
Add a new exception called ApplicationAlreadyInstalled that is given out when an application has already been installed.

Issue:

The domain manager register operations take in an object reference, so a callback is needed to get the identifier and profile attributes thus being inefficient.

 

Extent of Change: Major

 

Resolution:

Add to the DeviceManagerRegistration interface operations, identifier and profile parameters to eliminate the callbacks.

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

The base POSIX version of the AEP is being updated within the specification. In the update a new set of Error Conditions has been defined. The new error conditions need to be evaluated in order to determine whether or not they should be included within the specification.

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

Problem: Previous efforts to create an interface definition hierarchy and constraints on device components that would allow for light weight device component definitions has left some inconsistencies in the definitions, and did not address the resource components.  The real desire is to remove the constraints from the resource and device definitions to allow for both simple and sophisticated definitions to be managed consistently.  For example, device compositions reference device components which inherit from device which inherit state management and capacity manager.  There is currently no way for a lightweight device to be part of the composition.

Proposed Solution: Modify both the Resource and Device interface sections to remove unwanted inheritance and add in constraints for building more sophisticated versions.  This will allow the base versions to be the generalization required for reference in other facilities to create the desired consistent behavior.

Specifically: 

 Remove inheritance dependency from Resource such that only the specializations of Identifier, Lifecycle (init, release) and ControllableComponent (start,stop) interfaces are included.  The remaining interfaces would remain without dependencies.  

Add constraints to the effect that: 

if a component has test properties then the component shall realize the TestableObject Interface 
It a component has configure and/or query properties then the component shall realize the PropertySet interface. 
If a component has provides ports then the component shall realize the PortSupplier interface. 
If a component has uses ports then the component shall realize the PortConnector interface. 
Remove the inheritance dependency on CapacityManager and StateManagement from the Device interface.  Leave these interfaces as standalone interfaces.  

Add Device Component constraints to the effect that: 

if the component manages service properties then the component shall realize the CapacityManager interface 
is the component has managed service properties then the component shall realize the PropertySet interface. 
Also add sematics to the effect that if the DeviceComponent is suppose to be a managed component then it would realize the StatementManagement interface.

Move the methods contained in loadable and executable back into the LoadableDevice and ExecutableDevice respectively as with the revised definition of Device, these could be used as desired without the separate interfaces.

Then clean up any wording, etc. to ensure the any and all mixes can play together nicely. 

Resolution:
Modify both the Device Components section to remove unwanted inheritance and add in constraints and semantics for building more sophisticated DeviceComponents.  This will allow the base versions to be the generalization required for reference in other facilities to create the desired consistent behavior.

Add constraints to Component stereotype definition: 

§	If a component has test properties then the component shall realize the TestableObject Interface 
§	If a component has configure and/or query properties then the component shall realize the PropertySet interface. 
§	If a component has provides ports then the component shall realize the PortSupplier interface. 
§	If a component has uses ports then the component shall realize the PortConnector interface. 

Add to the semantics to Component as follows: A Component could also take on additional behavior for life cycle management by realizing the LifeCycle interface that would be used during deployment and teardown of a component. A Component may also realize the ControllableComponent interface to provide overall management control of the component.

Remove the inheritance dependency on CapacityManager, StateManagement, and Resource from the Device interface.  Leave these interfaces as standalone interfaces. 

Move the Semantics for Device interface to DeviceComponent definition.

Remove DeviceComposition attribute from Device interface.

Remove specialization of ManagedServiceComponent from DeviceComponent. DeviceComponent should be a specialization of Component and ServiceComponent. 

Add DeviceComponent constraints to the effect that: 

§	If the component manages service properties then the component shall realize the CapacityManager interface 
§	If the component has managed service properties then the component shall realize the PropertySet interface. 

Also add semantics DeviceComponent as follows:  A DeviceComponent can be extended with additional behavior such as the Resource interfaces. A DeviceComponent that manages IO communication equipment such as serial and audio would typically be extended by realizing the Resource interface. For DeviceComponents that are composite of DeviceComponents, the composite DeviceComponent would realize the DeviceComposition interface. For DeviceComponents that are managed they would also be stereotype as ManagedServiceComponent that realizes the StateManagement interface. Typically components who manage their capacities are managed components.

Move the methods contained in loadable and executable back into the LoadableDevice and ExecutableDevice respectively as with the revised definition of Device, these could be used as desired without the separate interfaces. Remove Loadable and Executable interfaces.

Update the ApplicationManager and ApplicationFactoryComponent M1 Illustrations Figures based upon the above changes.

Update the SerialComponent and AudioComponent Stereotypes in Communication Channel profile to be DeviceComponent and ResourceComponent.

Stereotypes Tables are missing text in constraints column. 

Proposed Solution: Add “See constraints in section below” in stereotypes tables that are missing the information

Resolution:

Add "See constraints in section below" in stereotypes tables that are missing the information or replace text that is incomplete. This change is consistent with the spec.

Unable to create Library stereotype based on definition in spec and Missing ComponentExecutableCode artifact that resourceexecutablecode should be a specialization of

Resolution:
Rename Library to be LibraryCode to avoid naming conflict.

ComponentExecutableCode name replaces ResourceExecutableCode, a broader concept to allow any component manifestation.

Remove BasicDeploymentRequirement and DeploymentRequirementQualifier types from spec.

Add to DeploymentRequirement a value attribute whose type is a ServiceProperty.

In Section 6.1 of the PIM & PSM for SW Radio intro book dtc/06-04-18,
currently under DTC vote, one finds these references to Life Science specs:


===============================
* Life Sciences Identifiers (LSID) - There are many
cross references in the model defined by this specification. They are
expressed using LSIDs. The relevant specification
is available as OMG documents: formal/04-12-01 and dtc/04-08-03.
* Genomic Map (GM) - The definitions in GM
specification are either too limiting or too generic for SNPs purposes.
The GM was designed at the time when genetic maps
were the only genome wide maps. Current focus is on sequence
maps.
===============================


Presumably this is a cut-n-paste error/artifact, and should be repaired.
The reference to BQS may be spurious as well.

I believe there is an error in Figure 7.1 in the "Component Document Type Definition Specification" dtc/06-04-22. Please note that the "DevicePackageDescriptor" is NOT showing any dependency on "Properties". This is a defined relationship in SCA 2.2.2.

 

Proposed Resolution: DPD ----> (0..*) Properties

Table 7.2 shows 11 stereotypes, but the 7.1.4 subsections support only 2 of them (RequiresPort and StreamPort). The other 9 are NOT detailed.
 

Recommendation:
Complex data type should be defined in UML Profile for SWRadio.

Resolution:
Mark have requested SBC DTF to consider this problem.

The meta-model needs to allow implementation properties (e.g., entry point arguments for environment types) to be defined at the implementation level