Issues for 2nd PIM & PSM For Software Radio Revision Task Force
To comment on any of these issues, send email to swradio-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
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 Section 8.5
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 8988: Invalid ServiceProperty’s capabilityModel attribute Type (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary:
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:
Revised Text: In section 8.1.3.12 ServiceProperty, Attributes noheader section
Change
"capabilityModel: Boolean"
To
"capabilityModel: String"
In the UML profile for SWRadio make similar change as stated above.
Actions taken:
September 15, 2005: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Make ServiceProperty's capabilityModel attribute type a string.
Issue 9229: Flexibility to Perform Allocation, Load and Execute Behavior (swradio-rtf)
Click here for this issue's archive.
Source: Boeing (Ms.Neli Hayes, persnaz.n.hayes@boeing.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: The changes to the Component Framework volume spec are as follows:
Replace Figure 7.9 - Device Component Interfaces Definition with the following figure
Add the following text to end of 7.1.5.1 Device Component Interfaces
"Types and Exceptions
o <<exception>>InvalidState (msg: String)
The InvalidState exception indicates that the device is not capable of the operation being attempted due to its state(s)
(e.g., admin, operational or usage)."
Change 7.1.5.1.1 Device description as follows:
From
"Description
The Device, as shown in Figure 7.9, defines an interface that abstracts the underlying hardware. The Device is a specialization of Resource and ManagedServiceComponent interfaces with additional capacity behavior."
To
"Description
The Device, as shown in Figure 7.9, defines an interface that abstracts the underlying hardware. The Device is a specialization of Resource, CapacityManager, and ManagedServiceComponent interfaces with additional attributes and release behavior."
7.15.1.1 Device
Attributes section remains
Remove Exception section and its contents
Create a new section before 7.1.5.1.1 Device as follows:
"7.1.5.1.1 CapacityManager
Description
The CapacityManager, as shown in Figure 7.9, defines an interface that provides the mechanisms for managing capacities.
Operations
Move the allocateCapacities and deallocateCapacities operations from 7.1.5.1.1 Device to here. Remove "<<optional>>" from text.
Types and Exceptions
Move the InvalidCapacity Exception from 7.1.5.1.1 Device to Here."
Rename 7.1.5.1.2 ExecutableDevice as Executable and change description as follows:
"Description
The Executable interface, as shown in Figure 7.9, provides generic execute and terminate behavior."
Add a new section after 7.1.5.1.2 Executable called ExecutableDevice with a description as follows:
"Description
The ExecutableDevice interface, as shown in Figure 7.9, extends the LoadableDevice by adding execute and terminate behavior."
Rename 7.1.5.1.4 LoadableDevice as Loadable and change description as follows:
"Description
The LoadableDevice interface, as shown in Figure 7.9, provides generic software loading and unloading behavior."
Add a new section after 7.1.5.1.4 Loadable called LoadableDevice with a description as follows:
"Description
The LoadableDevice interface, as shown in Figure 7.9, extends the Device interface by adding software loading and unloading behavior."
7.2.1.1.1 CapabilityModel
Replace Figure 7.21 - CapabilityModels Definition with the following figure
7.2.1.1.1 CapabilityModel, M1 Associations section
From
"o serviceProperty: ServiceProperty [1]
A ServiceProperty is associated with a CapabilityModel that determines the feasibility of the ServiceProperty satisfying a deployment requirement."
To
"o serviceProperty: ServiceProperty [1..n]
A ServiceProperty(s) is associated with a CapabilityModel that determines the feasibility of the ServiceProperty(s) satisfying a deployment requirement."
7.2.3.2.3.1 ApplicationManager, Figure 7.40 - ApplicationManager Definition replace figure as follows:
This figure has precedence over issue 9612 resolution.
7.2.3.2.4 ApplicationFactoryComponent
Replace Figure 7.41 - ApplicationFactory Capability Manager Relationshipswith the following figure
Replace Figure 7.42 - ApplicationFactory M1 Illustration with the following figure
This figure has precedence over issue 9612 resolution.
7.2.3.2.4 ApplicationFactoryComponent, Constraints section
From
"When capacityManager attribute is False the ApplicationFactoryComponent shall only use ServiceCapacityProperty(s) that are locally managed by a ManagedServiceComponent, otherwise the ApplicationFactory manages the ServiceCapacityProperty(s). Characteristic properties can be either managed or unmanaged by the ApplicationFactoryComponent."
To
"When capabilityManager attribute is False the ApplicationFactoryComponent shall only use ServiceProperty(s) that are locally managed by a ServiceComponent, otherwise the ApplicationFactory manages the ServiceProperty(s). Characteristic properties can be either managed or unmanaged by the ApplicationFactoryComponent."
Add constraints as follows:
"When the capabilityManager attribute is true then the ApplicationFactoryComponent shall support the ServiceProperty's capabilityModel for CapacityProperty."
"The ApplicationFactoryComponent shall support the ServiceProperty's capabilityModels for CharacteristicProperty, CharacteristicSelectionProperty, and CharacteristicSetProperty. Characteristic properties can be either managed or unmanaged by a ServiceComponent"
Make the following changes in the Component Framework profile and Devices.idl file.
Actions taken:
December 6, 2005: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9231: Inconsistent use of the term "Facility or Facilities" (swradio-rtf)
Click here for this issue's archive.
Source: L-3 Communications, Communication Systems - West (Mr. Mark Scoville, mark.scoville@L-3com.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In:
· section 4 sbc/06-04-08 (Common and Data Link Layer Facilities Specification)
· section 4 sbc/06-04-05 (Communications Channel and Equipment Specification),
· section 4 sbc/06-04-04 (Component Framework Specification)
· section 9.0 sbc/06-04-17 (PIM and PSM for Software Radio Components Specification Version 1.0)
change the definition of Facility from:
An environment providing a realization of certain functionality through set of well defined interfaces.
to:
The realization of certain functionality through a set of well defined interfaces.
In sbc/06-04-08 (Common and Datalink Layer Facilities Specification) section 7.0 change the following text from:
· Common Platform Facilities - This facility defines the set of services that all components within a platform can be used. Examples of these types of services are log, naming, and event service.
· Common Layer Facilities - This facility defines the set of interfaces that all components (regardless of any layering) within a platform can realize. Examples of these types of interfaces are flow control, packet, and stream interfaces.
· Data Link Layer Facilities - These facilities define Link Layer Control (LLC) and Medium Access Control (MAC) layer functionality for communication needs.
to:
· Common Platform Facilities - The set of interfaces that all components within a platform can be used. Examples of these types of services are log, naming, and event service.
· Common Layer Facilities - The set of interfaces that all components (regardless of any layering) within the radio can realize. Examples of these types of interfaces are flow control, packet, and stream interfaces.
· Data Link Layer Facilities - The set of interfaces that define Link Layer Control (LLC) and Media Access Control (MAC) layer functionality for communication needs.
In sbc/06-04-08 (Common and Datalink Layer Facilities Specification) section 7.2, change the following text from:
· Quality of Service Facilities - defines the quality of service related facilities.
· Flow Control Facilities - provides means to control communication flow so that a sender does not transmit more packets than a receiver can process.
· Measurement Facilities - specifies facilities to set up waveform related measurement parameters and schedule the measurement.
· Error Control Facilities -- allows the Receiver to tell the Sender about frames damaged or lost during transmission, and coordinates the re-transmission of those frames by the Sender.
· PDU Facilities - defines the Protocol Data Unit (PDU) building block concept that can be used in connectionless communication among radio sets as well as inter-component communication within a radio.
· Stream Facilities - defines the stream building block concept that can be used in connection-oriented communication among radio sets as well as inter-component communication within a radio.
to:
· Quality of Service Facilities - The set of interfaces that define the quality of service related functionality.
· Flow Control Facilities - The set of interfaces that control communication flow between senders and receivers.
· Measurement Facilities - The set of interfaces that provide measurement parameters and intervals.
· Error Control Facilities - The set of interfaces that allow the Receiver to tell the Sender about frames damaged or lost during transmission, and coordinates the re-transmission of those frames by the Sender.
· PDU Facilities - The set of interfaces that define the Protocol Data Unit (PDU) used in communication among radio sets as well as inter-component communication within a radio.
· Stream Facilities - The set of interfaces that define the stream concept used in communication among radio sets as well as inter-component communication within a radio.
In sbc/06-04-05 (Communications Channel and Equipment Specification) section 8, change the following text from:
· Physical Layer Facilities - These facilities define the functionality to convert the digitized signal into a propagating RF wave, and conversely, to convert a propagating RF wave into a digitized signal for processing. The facilities also include frequency tuning, filters, interface cancellation, analog digital conversion, up/down conversion, gain control, synthesizer, etc., functionality. Lastly, the Facilities have Input and Output (I/O) Facilities for serial and audio layer functionality.
· Radio Control Facilities consist of facilities that are used to manage the control of a RadioSet such as audio alarms, Radio Set configuration, and Radio Set channel management.
To:
· Physical Layer Facilities - The set of interfaces that define the functionality to convert the digitized signal into a propagating RF wave, and conversely, to convert a propagating RF wave into a digitized signal for processing. The facilities also include frequency tuning, filters, interface cancellation, analog digital conversion, up/down conversion, gain control, synthesizer etc., functionality. Physical layer facilities also include functionality for baseband I/O such as serial and audio devices.
· Radio Control Facilities - The set of interfaces that define the functionality to manage the radio domain and channels within the radio.
In sbc/06-04-17 (PIM and PSM for Software Radio Components Specification Version 1.0) section 9.0, change the following text from:
· Common Layer Facilities - This facility defines the set of interfaces that all components (regardless of any layering) within the radio can realize as described in reference 3.1.5.2. Examples of these types of interfaces are flow control, packet, and stream interfaces.\
· Common Radio Facilities - This facility defines the set of services that all components within the radio can be used. Examples of these types of services are log, naming, and event service as described in reference 3.1.3.
· Data Link Layer Facilities - These facilities define Link Layer Control (LLC) and Media Access Control (MAC) layer functionality for communication needs as described in reference 3.1.5.2.
· Physical Layer Facilities - These facilities define the functionality to convert the digitized signal into a propagating RF wave, and conversely, to convert a propagating RF wave into a digitized signal for processing as described in reference 3.1.5.2. The facilities also include frequency tuning, filters, interface cancellation, analog digital conversion, up/down conversion, gain control, synthesizer, etc., functionality. Physical layer facilities also include functionality for baseband I/O such as serial and audio devices.
· Radio Control Facilities - These facilities define the functionality to configure, get status, and control the radio domain and channels within the radio as described in reference 3.1.5.
To:
· Component Framework Facilities - The set of interfaces that all components (regardless of any layering) within the radio can realize as described in reference 3.2.5. Examples of these types of interfaces are waveform, device, and platform management interfaces.
· Common Layer Facilities - The set of interfaces that all components (regardless of any layering) within the radio can realize as described in reference 3.2.1. Examples of these types of interfaces are flow control, packet, and stream interfaces.
· Common Radio Facilities - The set of interfaces that all components within the radio can use. Examples of these types of facilities are log, naming, and event service as described in reference 3.2.1.
· Data Link Layer Facilities - The set of interfaces that compose the Link Layer Control (LLC) and Media Access Control (MAC) layer functionality for communication needs as described in reference 3.2.1.
· Physical Layer Facilities - The set of interfaces that define the functionality to convert the digitized signal into a propagating RF wave, and conversely, to convert a propagating RF wave into a digitized signal for processing as described in reference 3.2.4. The facilities also include frequency tuning, filters, interface cancellation, analog digital conversion, up/down conversion, gain control, synthesizer etc., functionality. Physical layer facilities also include functionality for baseband I/O such as serial and audio devices.
· Radio Control Facilities - The set of interfaces that define the functionality to manage the radio domain and channels within the radio as described in reference 3.2.4.
Actions taken:
December 8, 2005: received issue
April 19, 2007: closed issue
Discussion: 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".
Issue 9297: Exception Definition Missing (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Add Exception stereotype to Table 8-3 - Interface & Port Stereotypes in Interface & Port Stereotypes section 8.1.4. Insert Exception in table in alphabetical order. Insert the following row in table.
Exception Classifier Represents an exception type that is raised by an operation and defined in an interface or package.
In the UML profile for SWRadio, add an Exception stereotype in the Interface and Port Stereotypes package of the UML Profile, which is an extension of Classifier.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9298: PropertyValue Definition Incomplete (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Add the following text to Base Types section 8.1.1 in alphabetical order.
"Any
Description
The Any data type represents a type that can take on any value."
In the UML profile for SWRadio, add Any type in Base Types package of the UML profile, which is an applied stereotype of UML dataType.
In section 8.1.1.22 PropertyValue, Attributes no header section
Change
"value: primitive datatype or Properties"
To
"value: Any"
In the UML profile for SWRadio, change PropertyValue value attribute type in Base Types package of the UML profile to the Any type.
Add the following text
"Basic types (e.g., Any, Object) map to CORBA types."
in section 10 Platform Specific Model (PSM) to end of the list of "The rule set for transforming UML packages, interfaces, types, and exceptions into CORBA constructs are as follows:". This change may be section 9 in the break out volume spec
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9299: Object Type Not Defined. (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: Object Type Not Defined. Object type not defined in PortConnection IF for the connection operation. Add Object type in the Base Types section.
Resolution:
Revised Text: Add the following text to Base Types section 8.1.1 in alphabetical order.
"Object
Description
The Object represents a type that is a reference to object instance."
In the UML profile for SWRadio, add Object in Base Types package of the UML profile, which is a class.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Add Object type in the Base Types section. Applied Stereotype for Object is a UML class.
Issue 9300: Wrong Stereotypes for Property Types (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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?
Resolution:
Revised Text:
Actions taken:
January 24, 2006: received issue
Issue 9301: Port Not Defined (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In Component Framework volume spec
7.1.4.1.5 PortSupplier, Types and Exceptions section
From
o PortType (name: String, object: Port)
PortType defines a structure that associates a name with a port.
To
o PortType (name: String, providesRef : Object)
PortType defines a structure that associates a provides name with a port reference.
Make the PSM PortSupplier IDL change too.
Replace Figure 7-2 in Base Types section 7.1.1 with the following Figure.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Change definition of PortType, use Object instead of Port.
Issue 9302: FileSystemComponent Constraint Missing (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: FileSystemComponent Constraint Missing. Missing FileSystem interface constraint for FileSystemComponent. Add constraint to FileSystemComponent definition as was done for other FileServices components.
Resolution:
Revised Text: Add the following text to the end of FileSystem Component section 8.3.1.4.8.
"Constraints
The FileSystemComponent shall realize the FileSystem interface."
In the UML profile for SWRadio, add constraint as stated above to the FileSystemComponent.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Add constraint to FileSystemComponent definition as was done for other FileServices components.
Issue 9303: LoadType Inconsistent (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: LoadType Inconsistent. The LoadType definition is inconsistent with text. Make the definition agree with text
Resolution:
Revised Text: In section 8.1.6.1.4 LoadableDevice, Types and Exceptions noheader section.
Change
"<<enumeration>>LoadType ( KERNEL_MODULE, DRIVER, DLL, EXECUTABLE) "
To
"<<enumeration>>LoadType ( KERNEL_MODULE, DRIVER, DLL, EXECUTABLE, SHARED_LIBRARY)"
In the UML profile for SWRadio, add "SHARED_LIBRARY" to the LoadType definition for LoadableDevice interface.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Make the definition agree with text by adding "SHARED_LIBRARY enumeration literal to definition.
Issue 9304: Add CharacteristicSelectionType Type Constraint (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: Add CharacteristicSelectionType Type Constraint. CharacteristicSelectionType needs another constraint for the type to be restricted to an enumeration type.
Resolution:
Revised Text:
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed no change
Discussion: 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
Issue 9305: LoadableDeviceComponent CharacteristicSetProperties Definition Incomplete (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Add the following text to Base Types section 8.1.1 in alphabetical order.
"<<structproperty>>NameVersionCharacteristic
Description
The NameVersionCharacteristic type defines a characteristic that consists of a name and a version pair, which can be used for runtime, library, and os characteristic definitions."
Attributes
? name: String
The name attribute identifies the element.
? version: String
The version attribute identifies the version of the element."
In the UML profile for SWRadio, add NameVersionCharacteristic in Base Types package of the UML profile as defined above.
In section 8.1.6.2.5 LoadableDeviceComponent, Attribute noheader section
Change
"? <<characteristicsetproperty>> os(name = "OS", characteristic [1] = (qualifier [1] = (name ="Name", value = ""), qualifier [2] = ( name ="Version"," value = "")))
The <<characteristicsetproperty>> (Application and Device Components::Properties) os defines the type of Operating Systems supported for theLoadableDevice load operation. The OS name values are case sensitive. Thevalue attributes are device specific.
? <<characteristicsetproperty>>runtime( name = "Runtime",characteristic [1] = ( qualifier [1] = ( name ="Name",value = ""), qualifier [2] = ( name ="Version", value = "")))
The <<characteristicsetproperty>> (Application and Device Components::Properties) runtime defines the runtime environements supported for the LoadableDevice load operation. The value attributes are device specific.
? <<characteristicsetproperty>>library( name = "Library",characteristic [1] = ( qualifier [1] = ( name ="Name",value = ""), qualifier [2] = ( name ="Version", value = "")))
The <<characteristicsetproperty>> (Application and Device Components::Properties) library defines the libraries supported for the LoadableDevice load operation. The value attributes are device specific."
To
""? <<characteristicsetproperty>> os: NameVersionCharacteristic[1..*]
The <<characteristicsetproperty>> (Application and Device Components::Properties) os defines the type of Operating Systems supported for the LoadableDevice load operation. The OS name values are case sensitive. The value attributes are device specific.
? <<characteristicsetproperty>>runtime: NameVersionCharacteristic[*]
The <<characteristicsetproperty>> (Application and Device Components::Properties) runtime defines the runtime environments supported for the LoadableDevice load operation. The value attributes are device specific.
? <<characteristicsetproperty>>library: NameVersionCharacteristic[*]
The <<characteristicsetproperty>> (Application and Device Components::Properties) library defines the libraries supported for the LoadableDevice load operation. The value attributes are device specific."
In the UML profile for SWRadio, modify the library, os, and runtime properties for LoadableDeviceComponent as defined above.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9306: ConfigureProperty Errors (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: ConfigureProperty Errors. Configure property needs to be a type of radio property and type constraint is missing (see QueryProperty constraint).
Resolution:
Revised Text: In section 8.1.3 Properties, Table 8-2 - Properties Stereotypes
Change
"
ConfigureProperty Property N/A stepSize See constraints in section below Represents a configurable and queryable property.
QueryProperty Property SimpleProperty See constraints in section below Represents a queryable property
"
To
"
ConfigureProperty Property RadioProperty stepSize See constraints in section below Represents a configurable and queryable property.
QueryProperty Property RadioProperty See constraints in section below Represents a queryable property
"
In section 8.1.3.5 ConfigureProperty
Change
"Description
The ConfigureProperty indicates a configurable and queryable property. There are four types of ConfigureProperty, which are: primitive types, primitive sequence types, StructProperty and StructProperty sequences."
To
"Description
The ConfigureProperty, a type of Property, indicates a configurable and queryable property. There are four types of ConfigureProperty, which are: primitive types, primitive sequence types, StructProperty and StructProperty sequences."
In section 8.1.3.5 ConfigureProperty, Constraints noheader section
Add the following text.
"The type for ConfigureProperty shall be constrained to be primitive and StructProperty types."
In the UML profile for SWRadio, Change the ConfigureProperty in Properties package of the UML profile, as stated above.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Make ConfigureProperty a type of RadioProperty. Add QueryProperty constraint also for ConfigureProperty definition.
Issue 9307: Missing type for loadKind property for loadabledevicecomponent (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: Missing type for loadKind property for loadabledevicecomponent. In loadKind attribute text replace “(name = "Load Kind", type = string)” with LoadType [1..*].
Resolution:
Revised Text: In section 8.1.6.2.5 LoadableDeviceComponent, Attibutes noheader section
Change
"<<characteristicselectionproperty>> loadKind(name = "Load Kind", type = string)"
To
"<<characteristicselectionproperty>> loadKind: LoadType[1..*]"
In the UML profile for SWRadio, change loadKind property as defined above.
Actions taken:
January 24, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
In loadKind attribute text replace "(name = "Load Kind", type = string)" with LoadType [1..*].
Issue 9308: Constant Interface Definitions Invalid (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In section 8.1.4 Interface and Port Stereotypes, Table 8-3 - Interface & Port Stereotypes
Add row to table in alphabetical order by name.
"
Constant Property N/A N/A Static is true Represents a static property that is visible.
"
In the UML profile for SWRadio, add Constant in Interface and Port package of the UML profile, which is an extension of UML Property.
In section 8.1.6.1.2 ExecutableDevice, Types and Exceptions noheader section
Remove the Following items
"? PRIORITY_ID : String = "PRIORITY"
The PRIORITY_ID is the identifier for the ExecutableDevice's execute options parameters. The value for a priority option parameter shall be an unsigned long.
? STACK_SIZE_ID = "STACK_SIZE"
The STACK_SIZE_ID is the identifier for the ExecutableDevice's execute options parameter. The value for a stack size option parameter shall be an unsigned long.
? CREATE_THREAD_REQUEST = "CREATE_THREAD"
The CREATE_THREAD_REQUEST is the identifier for the ExecutableDevice's execute options parameter. The value for create thread request option shall be an unsigned long that indicates the thread ID to be collocated with. A zero valid indicates no thread ID collocation is indicated. A non-zero indicates the thread ID to be collocated with.
? RUNTIME_REQUEST = "RUNTIME_REQUEST"
The RUNTIME_REQUEST is the identifier for the ExecutableDevice's execute options parameter. The value for runtime request option shall be a string of the runtime name to be executed.
? RUNTIME_OPTIONS = "RUNTIME_OPTIONS"
The RUNTIME_OPTIONS is the identifier for the ExecutableDevice's execute options parameter. The value for runtime options option shall be a Base-Types::Properties. Each ID/value pair in the Properties represents a runtime option. The id indicates the option name and the value is the option value."
In section 8.1.6.1.2 ExecutableDevice,
Add the following Attributes noheader section after the Description noheader section
"Attributes
"? <<constant>>PRIORITY_ID : String = "PRIORITY"
The PRIORITY_ID is the identifier for the ExecutableDevice's execute options parameters. The value for a priority option parameter shall be an unsigned long.
? <<constant>>STACK_SIZE_ID: String = "STACK_SIZE"
The STACK_SIZE_ID is the identifier for the ExecutableDevice's execute options parameter. The value for a stack size option parameter shall be an unsigned long.
? <<constant>>CREATE_THREAD_REQUEST: String = "CREATE_THREAD"
The CREATE_THREAD_REQUEST is the identifier for the ExecutableDevice's execute options parameter. The value for create thread request option shall be an unsigned long that indicates the thread ID to be collocated with. A zero valid indicates no thread ID collocation is indicated. A non-zero indicates the thread ID to be collocated with.
? <<constant>>RUNTIME_REQUEST: String = "RUNTIME_REQUEST"
The RUNTIME_REQUEST is the identifier for the ExecutableDevice's execute options parameter. The value for runtime request option shall be a string of the runtime name to be executed.
? <<constant>>RUNTIME_OPTIONS: String = "RUNTIME_OPTIONS"
The RUNTIME_OPTIONS is the identifier for the ExecutableDevice's execute options parameter. The value for runtime options option shall be a Base-Types::Properties. Each ID/value pair in the Properties represents a runtime option. The id indicates the option name and the value is the option value."
In the UML profile for SWRadio, add Constant properties in the ExecutableDevice interface as stated above.
In section 8.3.1.4.3 FileSystem, Types and Exceptions noheader section
Remove the Following items
"? SIZE : constant String = "SIZE"
Property name for file system's total size.
? AVAILABLE_SPACE : constant String := "AVAILABLE_SPACE"
Property name for file system's available unused space
? CREATED_TIME_ID : constant String = "CREATED_TIME".
The CREATED_TIME_ID is the identifier for the created time file property. A created time property indicates the time the file was created.
? MODIFIED_TIME_ID : constant String ="MODIFIED_TIME"
The MODIFIED_TIME_ID is the identifier for the modified time file property. The modified time property is the time the file data was last modified.
? LAST_ACCESS_TIME_ID : constant String = "LAST_ACCESS_TIME"
The LAST_ACCESS_TIME_ID is the identifier for the last access time file property. The last access time property is the time the file was last access (e.g. read)."
In section 8.3.1.4.3 FileSystem
Add the following Attributes noheader section after the Description noheader section
"Attributes
? <<constant>>SIZE : String = "SIZE"
Property name for file system's total size.
? <<constant>>AVAILABLE_SPACE : String := "AVAILABLE_SPACE"
Property name for file system's available unused space.
? <<constant>>CREATED_TIME_ID : String = "CREATED_TIME".
The CREATED_TIME_ID is the identifier for the created time file property. A created time property indicates the time the file was created.
? <<constant>>MODIFIED_TIME_ID : String ="MODIFIED_TIME"
The MODIFIED_TIME_ID is the identifier for the modified time file property. The modified time property is the time the file data was last modified.
? <<constant>>LAST_ACCESS_TIME_ID : String = "LAST_ACCESS_TIME"
The LAST_ACCESS_TIME_ID is the identifier for the last access time file property. The last access time property is the time the file was last access (e.g. read).
In the UML profile for SWRadio, add Constant properties in the FileSystem interface as stated above.
Add the following text
"UML attributes with constant stereotype map to CORBA constants in CORBA interfaces."
in section 10 Platform Specific Model (PSM) to end of the list of "The rule set for transforming UML packages, interfaces, types, and exceptions into CORBA constructs are as follows:". This change may be section 9 in the break out volume spec.
Actions taken:
January 25, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9313: Application Stereotype Incomplete (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: 7.1.7 Application Components, Table 7.5 - Applications Stereotypes
From
Stereotype Base Class Parent Tags Constraints Description
Application component N/A Represents an assembly ofApplicationResources andComponents.
To
Stereotype Base Class Parent Tags Constraints Description
Application component N/A Seeconstraints insection below Represents an assembly ofComponents.
7.1.7 Application Components, Table 7.5 - Applications Stereotypes, Add ComponentInstantiation after ApplicationResourceComponent.
Stereotype Base Class Parent Tags Constraints Description
ComponentInstantiation Property N/A assemblerController,hostCollocation,namingService,processCollocationresourcefactory, Seeconstraints insection below Represents an Application part.
7.1.7 Application Components, Table 7.5 - Applications Stereotypes, Add ServiceConnector after PhysicalLayerResource.
Stereotype Base Class Parent Tags Constraints Description
ServiceConnector Connector N/A deviceThatLoadedComponentInstantiation,domainfinder,namingService,serviceComponentUsedByComponentInstantiation Seeconstraints insection below Represents a connector to a service, interface or ServiceComponent.
ServiceComponentInstantiation Property N/A Seeconstraints insection below Represents a service component within an Application.
7.1.7.1 Application, add constraints section after M1 Associations section and its text.
"Constraints
The Application needs one ComponentInstantiation to be noted as an assembly controller.
The Application shall only be composed of ComponentInstantiations and ServiceComponentInstantiations.
The Application shall have at least one ComponentInstantiation and its type is other than a ResourceFactoryComponent type.
A ComponentInstantiation's resourceFactory resourceFactoryCreateOptions attribute shall have an instance value that agrees with the attributes for the referenced ResourceFactoryComponent ComponentInstantiation's type.
A ComponentInstantiation's resourceFactory resourceFactoryInstantiationRef shall be to a valid ResourceFactoryComponent ComponentInstantiation reference within the Application.
A ServiceConnector is not depicted between ComponentInstantiations' connections."
Insert 7.1.7.3 ComponentInstantiation before 7.1.7.3 WaveFormLayerResource
"7.1.7.3 ComponentInstantiation
Description
The ComponentInstantiation, an extension of Property, defines a specific component type for an Application's part.
Attributes
§ assemblyController: Boolean = False
The assemblyController indicates whether or not the ComponentInstantiation is acting as the assembly controller for the assembly composition. A value of True means the ComponentInstantiation is an assembly controller.
§ hostCollocation: String [0..1]
The hostCollocation attribute identifies the requirement for a ComponentInstantiation on being deployed on the same device with other ComponentInstantiations that have the same hostCollocation attribute value.
§ processCollocation: String [0..1]
The processCollocation attribute identifies the requirement for a ComponentInstantiation on being deployed within the same process space with other componentInstantiations that have the same processCollocation attribute value.
§ namingService: String [0..1]
The namingService attribute specifies the simple name used by the deployment machinery such as ApplicationFactoryComponent in forming the naming context for where the ComponentInstantiation reference is placed in a naming service.
§ resourceFactory: ResourceFactoryType [0..1]
The resourceFactory attributes indicates to the deployment manchinery such as ApplicationFactoryComponent that the ComponentInstantiation is obtained by a ResourceFactoryComponent.
Constraints
The ComponentInstantiation's assemblyController attribute value shall only be True when the ComponentInstantiation type is a ResourceComponent or Component type.
The ComponentInstantiation's type shall be a ResourceFactoryComponent, ResourceComponent, Component, or Application.
The ComponentInstantiation shall have a value for either namingService or resourceFactory attribute.
The ComponentInstantiation's value shall be an instance value that agrees with the attributes for the ComponentInstantiation's type."
Insert new 7.1.7.4 and 7.1.7.5 before 7.1.7.4 PhysicalLayerResource
"7.1.7.4 ServiceComponentInstantiation
Description
The ServiceComponentInstantiation, an extension of property, defines a ServiceComponent type for an Application's part so one can show ComponentInstantiations connections to ServiceComponents. These components are not physical part of the Application but are platform ServiceComponents used by ComponentInstantiations.
Constraints
The ServiceComponentInstantiation's type shall be a ServiceComponent stereotype.
7.1.7.5 ServiceConnector
Description
The serviceconnector specifies to the deployment machinery such as ApplicationFactoryComponent on how to obtain the ServiceComponent reference that is participating in the connections. ServiceConnector is used for connection to platform ServiceComponents and their interfaces that an Application's ComponentInstantiation is connected to.
Attributes
§ deviceThatLoadedComponentInstantiation: String [0..1]
§ DomainFinder: DomainFinderType [0..1]
§ namingService: String [0..1]
The namingService attribute specifies a full naming context that identifies the location of the ServiceComponent reference in a naming service.
§ serviceUsedByComponentInstantiation: ServiceComponent [0..1]
Constraints
A ServiceConnector needs to have a value specified for one of its attributes."
7.1.7 Application Components
From
"The Application Components sections define the set of components used to define applications and waveforms. The Application Components stereotypes are depicted in Table 7.5, which are extensions of the UML Component (UML2.0::Components::BasicComponents). The following subsections describe the details of these elements."
To
"7.1.7.1 Application Components Types
The Application Component Types define the types used by some of the Application stereotypes definitions.
Types and Exceptions
§ DomainFinderType(name: String, type: String)
The DomainFinderType is used to specify information about a ServiceComponent that a component such as DomainManagerComponent is aware of. The name attribute indicates the name of the ServiceComponent and type attribute indicates the type of ServiceComponent (e.g., log service, event service, etc.).
§ ResourceFactoryType(resourceFactoryInstantiationRef: String, resourceFactoryCreateOptions: ResourceFactoryComponent)
The ResourceFactoryType, a dataType, specifies the ResourceFactoryComponent instantiation element to use to obtain a ComponentInstantiation reference by the resourceFactoryInstantiationRef. The resourceFactoryCreateOptions are the options parameter values to be used for the ResourceFactoryComponent create operation.
7.1.7.2 Application Components Stereotypes
The Application Components Stereotypes section defines the set of components used to define applications and waveforms. The Application Components stereotypes are depicted in Table 7.5, which are extensions of the UML Component (UML2.0::Components::BasicComponents). The following subsections describe the details of these elements."
Actions taken:
January 26, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9314: Code Artifact Manifest Constraint Missing (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In section 8.3.4.1.2.1 ExecutableCode, Constraints noheader section
Add the following text at end of section
"A ExecutableCode shall manifest a Component."
In section 8.3.4.1.2.3 LogicalDeviceExecutableCode, Constraints noheader section
Add the following text at end of section
"A LogicalDeviceExecutableCode shall manifest a DeviceComponent."
In section 8.3.4.1.2.5 ResourceExecutableCode, Constraints noheader section
Add the following text at end of section
"A ResourceExecutableCode shall manifest a ResourceComponent or ResourceFactoryComponent."
In section 8.3.4.1.2.6 ServiceExecutableCode, Constraints noheader section
Add the following text at end of section
"A ServiceExecutableCode shall manifest a ServiceComponent."
In UML Profile for SWRadio, add constraints as defined above to the executable artifacts in profile.
Actions taken:
January 27, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
ServiceExecutableCode shall manifest a ServiceComponent
ResourceExecutableCode shall manifest a ResourceComponent and/or ResourceFactoryComponents
LogicalDeviceExecutableCode shall manifest a DeviceComponent type.
Issue 9315: ExecutableCode Constraint Missing (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: For ExecutableCode add a constraint on properties being executableproperty types
Resolution:
Revised Text: In section 8.3.4.1.2.1 ExecutableCode, Constraints noheader section
Add the following text at end of section
"ExecutableCode properties shall be of type ExecutableProperty."
In UML Profile for SWRadio, add constraint as defined above to the executablecode artifacts in profile.
Actions taken:
January 27, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
For ExecutableCode add a constraint on properties being executableproperty types.
Issue 9316: Make Descriptor and LoadableCode a parent of File. (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary:
Resolution:
Revised Text: In section 8.3.4.1.2 SWRadio Artifacts Stereotypes, Table 8-12 - SWRadio Artifacts Stereotypes
Change corresponding rows in table from
"
Descriptor Artifact N/A Indicates an artifact that is a deployment or component specification that conveys information on the element to be deployed.
LoadableCode Artifact N/A Indicates an artifact that defines the base SWRadio artifact definition and relationships for any type of SWRadio artifact.
"
To
"
Descriptor Artifact File Indicates an artifact that is a deployment or component specification that conveys information on the element to be deployed.
LoadableCode Artifact File Indicates an artifact that defines the base code artifact definition and relationships for any type of component artifact.
"
In the UML profile for SWRadio, make Descriptor and LoadableCode a File artifact type definition as stated above.
Actions taken:
January 27, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Replace N/A in table with File.
Issue 9317: Add other Descriptor Types (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: Add other Descriptor Types that are specialization of Descriptor, such as PropertiesDescriptor, SoftwareComponentDescriptor, SoftwarePkgDescriptor, SoftwareAssemblyDescriptor, DeviceConfigurationDescriptor, DeviceDescriptor, and DomainManagerDescriptor
Resolution:
Revised Text: In section 8.3.4.1.2 SWRadio Artifacts Stereotypes, Table 8-12 - SWRadio Artifacts Stereotypes
Add corresponding rows in table in alphabetical order
"
DeviceConfigurationDescriptor Artifact Descriptor Indicates a descriptor that describes the service components configuration for a node.
DeviceDescriptor Artifact Descriptor Indicates a descriptor that describes a device.
DomainManagerDescriptor Artifact Descriptor Indicates a descriptor that describes a domain manager component.
PropertiesDescriptor Artifact Descriptor Indicates a descriptor that describes properties for a component definition or implementation.
SoftwareAssemblyDescriptor Artifact Descriptor Indicates a descriptor that describes an application assembly to be deployed.
SoftwareComponentDescriptor Artifact Descriptor Indicates a descriptor that describes a component definition to be deployed.
SoftwarePkgDescriptor Artifact Descriptor Indicates a descriptor that describes a component implementation to be deployed.
"
In the UML profile for SWRadio, add descriptor types to profile as stated above.
Actions taken:
January 27, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Add other Descriptor types that are specialization of Descriptor, such as PropertiesDescriptor, SoftwareComponentDescriptor, SoftwarePkgDescriptor, SoftwareAssemblyDescriptor, DeviceConfigurationDescriptor, DeviceDescriptor, and DomainManagerDescriptor.
Issue 9331: Add Required and Provided ports definitions that are specialization of SWRa (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In section 8.1.4 Interface and Port Stereotypes, Table 8-3 - Interface & Port Stereotypes
Add rows to table in alphabetical order by name.
"
ProvidesPort Port Port Service is true Indicates a port that provides a specific type of service.
RequiresPort Port Port ConnectionThreshold Service is false Indicates a port that requires a specific type of service.
"
In section 8.1.4 Interface and Port Stereotypes, Table 8-3 - Interface & Port Stereotypes
Replace the corresponding row in table
"
SWRadioPort Port N/A Only associated with SWRAPI interfaces. Represents a SWRadio port that is associated with SWRAPIs
"
To
"
Port Port N/A A port can only be associated with one interface type. Represents a port with an interface type constraint.
"
Add new subsection to section 8.1.4 Interface and Port Stereotypes in alphabetical order as follows
"8.1.4.X RequiresPort"
Description
The RequiresPort defines a port that uses a specific service.
Attributes
? connectionThreshold: ULong
The ConnectionThreshold attribute determines the number of connections allowed for a requires port."
In the UML profile for SWRadio, add port types to profile as stated above and modify SWRadioPort as stated above.
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9332: SAD FindComponent Cardinality Error (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: For the componentinstantiation element the findcomponent cardinality cannot be optional
Resolution:
Revised Text:
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed no change
Discussion: 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
Issue 9333: Add SAD CollocationProcess Element. (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In section 8.1.5.2.3 SWRadioComponent, Semantics noheader section
Change 1st sentence
"L.6.3 partitioning.
A component partitioning element (see Figure L-106) specifies a deployment pattern of components and their components-to-hosts relationships. A component instantiation is captured inside a componentplacement element. The hostcollocation element allows the components to be placed on a common device. When the componentplacement is by itself and not inside a hostcollocation or processcollocation, it then has no collocation constraints.
<!ELEMENT partitioning
( componentplacement
| hostcollocation
)+>"
To
"L.6.3 partitioning (in break out spec 7.6.3)
A component partitioning element (see Figure 7.21) specifies a deployment pattern of components and their components-to-hosts and process relationships. A component instantiation is captured inside a componentplacement element. The hostcollocation element allows the components to be placed on a common device. The processcollocation element allows components to be placed within the same process space. When the componentplacement is by itself and not inside a hostcollocation, it then has no collocation constraints.
<!ELEMENT partitioning
( componentplacement
| hostcollocation
| processcollocation
)+>"
Update Figure 7.21 with following Figure
Change L.6.3.2 hostcollocation as follows:
From
"The hostcollocation element specifies a group of component instances that are to be deployed together on a single host. For purposes of the SWRadio, the componentplacement element will be used to describe the 1...n components that will be collocated on the same host platform. Within the SWRadio specification, a host platform will be interpreted as a single device. The id and name attributes are optional but may be used to uniquely identify a set of collocated components within a SAD file.
<!ELEMENT hostcollocation
( componentplacement
)+>
<!ATTLIST hostcollocation
id ID #IMPLIED
name CDATA #IMPLIED>"
To
"L.6.3.2 hostcollocation. The hostcollocation element specifies a group of component instances that are to be deployed together on a single host. The componentplacement element will be used to describe the 1...n components that will be collocated on the same host platform. The processcollocation element will be used to describe the processes that are to be collocated on the same host. A host platform will be interpreted as a single device. The id and name attributes are optional but may be used to uniquely identify a set of collocated components within a SAD file.
<!ELEMENT hostcollocation
( componentplacement
| processcollocation
)+>
<!ATTLIST hostcollocation
id ID #IMPLIED
name CDATA #IMPLIED>"
Add a new section after L.6.3.2 hostcollocation. (in break out spec section 7.6.3.2)
"L.6.3.3 processcollocation.
The processcollocation element specifies a group of component instances that are to be deployed together in a single process. The componentplacement element will be used to describe the 1...n components that will be collocated in the process. The id and name attributes are optional but may be used to uniquely identify a set of collocated components within a SAD file.
<!ELEMENT processcollocation
( componentplacement
)+>
<!ATTLIST processcollocation
id ID #IMPLIED
name CDATA #IMPLIED>"
Change Software Assembly Descriptor DTD in Domain Profile XML Files.
from
"<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT softwareassembly
( description?
, componentfiles
, partitioning
, assemblycontroller
, connections?
, externalports?
)>
<!ATTLIST softwareassembly
id ID #REQUIRED
name CDATA #IMPLIED
version CDATA #IMPLIED>
<!ELEMENT description (#PCDATA)>
<!ELEMENT componentfiles
( componentfile+
)>
<!ELEMENT componentfile
( localfile
)>
<!ATTLIST componentfile
id ID #REQUIRED
type CDATA #IMPLIED>
<!ELEMENT localfile EMPTY>
<!ATTLIST localfile
name CDATA #REQUIRED>
<!ELEMENT partitioning
( componentplacement
| hostcollocation
)+>
<!ELEMENT componentplacement
( componentfileref
, componentinstantiation+
)>
<!ELEMENT componentfileref EMPTY>
<!ATTLIST componentfileref
refid CDATA #REQUIRED>
<!ELEMENT componentinstantiation
( usagename?
, componentproperties?
, findcomponent?
)>
<!ATTLIST componentinstantiation
id ID #REQUIRED>
<!ELEMENT usagename (#PCDATA)>
<!ELEMENT componentproperties
( simpleref
| simplesequenceref
| structref
| structsequenceref
)+ >
<!ELEMENT findcomponent
( componentresourcefactoryref
| namingservice
)>
<!ELEMENT componentresourcefactoryref
( resourcefactoryproperties?
)>
<!ATTLIST componentresourcefactoryref
refid CDATA #REQUIRED>
<!ELEMENT resourcefactoryproperties
( simpleref
| simplesequenceref
| structref
| structsequenceref
)+ >
<!ELEMENT simpleref EMPTY>
<!ATTLIST simpleref
refid CDATA #REQUIRED
value CDATA #REQUIRED>
<!ELEMENT simplesequenceref
(values
)>
<!ATTLIST simplesequenceref
refid CDATA #REQUIRED>
<!ELEMENT structref
(simpleref+
)>
<!ATTLIST structref
refid CDATA #REQUIRED>
<!ELEMENT structsequenceref
( structvalue+
)>
<!ATTLIST structsequenceref
refid CDATA #REQUIRED>
<!ELEMENT structvalue
(simpleref+
)>
<!ELEMENT values
( value+
)>
<!ELEMENT value (#PCDATA)>
<!ELEMENT hostcollocation
( componentplacement
)+>
<!ATTLIST hostcollocation
id ID #IMPLIED
name CDATA #IMPLIED>
<!ELEMENT assemblycontroller
( componentinstantiationref
)>
<!ELEMENT connections
( connectinterface*
)>
<!ELEMENT connectinterface
( usesport
, ( providesport
| componentsupportedinterface
| findby
)
)>
<!ATTLIST connectinterface
id ID #IMPLIED>
<!ELEMENT usesport
( usesidentifier
, (componentinstantiationref
| devicethatloadedthiscomponentref
| deviceusedbythiscomponentref
| findby
)
)>
<!ELEMENT usesidentifier (#PCDATA)>
<!ELEMENT componentinstantiationref EMPTY>
<!ATTLIST componentinstantiationref
refid CDATA #REQUIRED>
<!ELEMENT findby
( namingservice
| domainfinder
)>
<!ELEMENT namingservice EMPTY>
<!ATTLIST namingservice
name CDATA #REQUIRED>
<!ELEMENT domainfinder EMPTY>
<!ATTLIST domainfinder
type CDATA #REQUIRED
name CDATA #IMPLIED>
<!ELEMENT devicethatloadedthiscomponentref EMPTY>
<!ATTLIST devicethatloadedthiscomponentref
refid CDATA #REQUIRED>
<!ELEMENT deviceusedbythiscomponentref EMPTY>
<!ATTLIST deviceusedbythiscomponentref
refid CDATA #REQUIRED
usesrefid CDATA #REQUIRED>
<!ELEMENT providesport
( providesidentifier
, ( componentinstantiationref
| devicethatloadedthiscomponentref
| deviceusedbythiscomponentref
| findby
)
)>
<!ELEMENT providesidentifier (#PCDATA)>
<!ELEMENT componentsupportedinterface
( supportedidentifier
, ( componentinstantiationref
| findby
)
)>
<!ELEMENT supportedidentifier (#PCDATA)>
<!ELEMENT externalports
(port+
)>
<!ELEMENT port
( description?
, (usesidentifier | providesidentifier | supportedidentifier)
, componentinstantiationref
)>"
To
"<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT softwareassembly
( description?
, componentfiles
, partitioning
, assemblycontroller
, connections?
, externalports?
)>
<!ATTLIST softwareassembly
id ID #REQUIRED
name CDATA #IMPLIED
version CDATA #IMPLIED>
<!ELEMENT description (#PCDATA)>
<!ELEMENT componentfiles
( componentfile+
)>
<!ELEMENT componentfile
( localfile
)>
<!ATTLIST componentfile
id ID #REQUIRED
type CDATA #IMPLIED>
<!ELEMENT localfile EMPTY>
<!ATTLIST localfile
name CDATA #REQUIRED>
<!ELEMENT partitioning
( componentplacement
| hostcollocation
| processcollocation
)+>
<!ELEMENT componentplacement
( componentfileref
, componentinstantiation+
)>
<!ELEMENT componentfileref EMPTY>
<!ATTLIST componentfileref
refid CDATA #REQUIRED>
<!ELEMENT componentinstantiation
( usagename?
, componentproperties?
, findcomponent?
)>
<!ATTLIST componentinstantiation
id ID #REQUIRED>
<!ELEMENT usagename (#PCDATA)>
<!ELEMENT componentproperties
( simpleref
| simplesequenceref
| structref
| structsequenceref
)+ >
<!ELEMENT findcomponent
( componentresourcefactoryref
| namingservice
)>
<!ELEMENT componentresourcefactoryref
( resourcefactoryproperties?
)>
<!ATTLIST componentresourcefactoryref
refid CDATA #REQUIRED>
<!ELEMENT resourcefactoryproperties
( simpleref
| simplesequenceref
| structref
| structsequenceref
)+ >
<!ELEMENT simpleref EMPTY>
<!ATTLIST simpleref
refid CDATA #REQUIRED
value CDATA #REQUIRED>
<!ELEMENT simplesequenceref
(values
)>
<!ATTLIST simplesequenceref
refid CDATA #REQUIRED>
<!ELEMENT structref
(simpleref+
)>
<!ATTLIST structref
refid CDATA #REQUIRED>
<!ELEMENT structsequenceref
( structvalue+
)>
<!ATTLIST structsequenceref
refid CDATA #REQUIRED>
<!ELEMENT structvalue
(simpleref+
)>
<!ELEMENT values
( value+
)>
<!ELEMENT value (#PCDATA)>
<!ELEMENT hostcollocation
( componentplacement
| processcollocation
)+>
<!ATTLIST hostcollocation
id ID #IMPLIED
name CDATA #IMPLIED>
<!ELEMENT processcollocation
( componentplacement
)+>
<!ATTLIST processcollocation
id ID #IMPLIED
name CDATA #IMPLIED>
<!ELEMENT assemblycontroller
( componentinstantiationref
)>
<!ELEMENT connections
( connectinterface*
)>
<!ELEMENT connectinterface
( usesport
, ( providesport
| componentsupportedinterface
| findby
)
)>
<!ATTLIST connectinterface
id ID #IMPLIED>
<!ELEMENT usesport
( usesidentifier
, (componentinstantiationref
| devicethatloadedthiscomponentref
| deviceusedbythiscomponentref
| findby
)
)>
<!ELEMENT usesidentifier (#PCDATA)>
<!ELEMENT componentinstantiationref EMPTY>
<!ATTLIST componentinstantiationref
refid CDATA #REQUIRED>
<!ELEMENT findby
( namingservice
| domainfinder
)>
<!ELEMENT namingservice EMPTY>
<!ATTLIST namingservice
name CDATA #REQUIRED>
<!ELEMENT domainfinder EMPTY>
<!ATTLIST domainfinder
type CDATA #REQUIRED
name CDATA #IMPLIED>
<!ELEMENT devicethatloadedthiscomponentref EMPTY>
<!ATTLIST devicethatloadedthiscomponentref
refid CDATA #REQUIRED>
<!ELEMENT deviceusedbythiscomponentref EMPTY>
<!ATTLIST deviceusedbythiscomponentref
refid CDATA #REQUIRED
usesrefid CDATA #REQUIRED>
<!ELEMENT providesport
( providesidentifier
, ( componentinstantiationref
| devicethatloadedthiscomponentref
| deviceusedbythiscomponentref
| findby
)
)>
<!ELEMENT providesidentifier (#PCDATA)>
<!ELEMENT componentsupportedinterface
( supportedidentifier
, ( componentinstantiationref
| findby
)
)>
<!ELEMENT supportedidentifier (#PCDATA)>
<!ELEMENT externalports
(port+
)>
<!ELEMENT port
( description?
, (usesidentifier | providesidentifier | supportedidentifier)
, componentinstantiationref
)>"
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Add an optional processcollocation element to the partitioning and hostcollocation element definitions.
Issue 9334: SAD ComponentInstantiation Description Error (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity: Significant
Summary: 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:
Revised Text: In section L.6.3.1.2 componentinstantiation (break out volume 7.6.3.2.1), change the following sentence
from
"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 7.24) 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 "configure" or "factoryparm" kinds of property definitions as stated in the corresponding SCD. The "execparm" kind of property definitions as stated in the corresponding SPD.
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"::
1. The componentproperties element of the componentinstantiation element in SAD.
The following sources will be searched in the given precedence order for initial values for the "execparam" kind of properties:
1. The componentproperties element of the componentinstantiation element in SAD or the componentinstantiation element's findcomponent element's componentresourcefactoryref element's resourcefactoryproperties element in the 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."
to
"The componentinstantiation element (see Figure 7.23) 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.
The optional componentproperties element (see Figure 7.24) 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 7.25) 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 7.26), 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., non-CORBA 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."
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9335: L.2.1 Software Package Desription (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In section L.2.1 Software Package (break out volume 7.2.1), change the following sentence
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."
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: 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."
Issue 9336: ServiceComponent Definition Issue (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In section 8.3.1.3 ServiceComponent, Description noheader section
Change
"The abstract ServiceComponent, as shown in Figure 8-32, offers service(s) within the radio environment, which can be used by SWRadioComponent(s). The potential Service(s) offered by a ServiceComponent are depicted in the Types and Exceptions section below."
To
"The ServiceComponent, as shown in Figure 8-32, offers service(s) within the radio environment, which can be used by Component(s). For example, the potential Service(s) offered by a ServiceComponent are log, event, and naming."
In the UML profile for SWRadio, make ServiceComponent not abstract in the profile as stated above.
In section 8.3.1.3 ServiceComponent, Remove Types and Exceptions noheader section and its contents.
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Make ServiceComponent non-abstract type and remove type definitions from stereotype definition
Issue 9346: ApplicationResourceComponent Definition (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: ApplicationResourceComponent Definition. ApplicationResourceComponent needs to a specialization of ResourceComponent
Resolution:
Revised Text: In section 8.1.7.2 ApplicationResourceComponent, Description noheader section
Change 1st sentence
"The ApplicationResourceComponent, as shown in Table 8-6, provides a common API for control and configuration of an application resource component."
To
"The ApplicationResourceComponent, a specialization of ResourceCompoent as shown in Table 8-6, provides a common API for control and configuration of an application resource component."
Actions taken:
February 1, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Change ApplicationResourceComponent description to include that the component is a specialization of ResourceComponent.
Issue 9347: SWRadioComponent additional constraint (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: SWRadioComponent additional constraint. SWRadioComponent needs a constraint that when connected to a log service, the ProducerLOGLevel property shall be supported
Resolution:
Revised Text: In section 8.1.5.2.3 SWRadioComponent, Semantics noheader section
Change 1st sentence
"SWRadioComponent may implement a ConfigureProperty with a name of "PRODUCER_LOG_LEVEL"."
To
"SWRadioComponent shall implement a ConfigureProperty with a name of "PRODUCER_LOG_LEVEL when connected to a log service."
Actions taken:
February 1, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Add requirement that the SWRadioComponent shall support the ProducerLogLevel when the component is connected to a log service.
Issue 9348: Oneway operation stereotype (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In Component Framework volume spec
7.1.3 Interface and Port Stereotypes, Table 7.2 - Interface & Port Stereotypes
Add row in after row IStreamControl
Stereotype Base Class Parent Tags Constraints Description
Oneway Operation The operation may not have any return parameters and nor exceptions. Represents an asynchronous interaction between a caller and a receiver where the caller proceeds immediately after making the call.
Add to Component Framework Profile
Actions taken:
February 1, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Add oneway stereotype to 7.1.3 Interface and Port Stereotypes
Issue 9349: Simple Property Datatype (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
February 1, 2006: received issue
Discussion: Discussion:
This issue is deferred to the follow-on RTF, since RTF #1 ran out of time.
Disposition: Deferred
Issue 9350: AntennaElement (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: AntennaElement. AntennaElement not in Communication Equipment Stereotype table
Resolution:
Revised Text: Add AntennaElement after Antenna in Table 7.1 - Communication Equipment Stereotypes in Comm Channel and Equipment volume spec as follows:
Stereotype Base Class Parent Tags Constraints Description
AntennaElement Device IODevice polarization,positionInAntennaArray,radiationPattern,type,active Seeconstraints insection below Translates electrical energy into an electromagnetic wave and vice-versa.
Actions taken:
February 1, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Add AntennaElement to Communication Equipment Stereotype table.
Issue 9469: PIM and PSM SWRadio Spec Figures Issue (swradio-rtf)
Click here for this issue's archive.
Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: In the breakout volume spec, Component Framework make the following changes
Update Figure 7.7 - ResourceFactoryComponent M1 Illustration with following figure
Update Figure 7.12 - ExecutableDeviceComponent M1 Illustration with following figure
Update Figure 7.13 - LoadableDeviceComponent M1 Illustration with following figure
Update first sentence in section 7.2.3.2.1.1 Application as follows:
"The Application interface provides for the control, configuration, and status of an instantiated application or waveform in the domain."
With
"The Application interface, as shown in Figure 7.38, provides for the control, configuration, and status of an instantiated application or waveform in the domain."
Add Figure 7.38 - Application Definition
Replace the following text in section 7.2.3.2.2 ApplicationFactory
"The ApplicationFactory interface provides the dynamic mechanism to create a specific type of Application (e.g.waveform) in the domain. Figure 7.39 depicts the ApplicationFactory's capacity constraints and Figure 7.40 depicts the relationships that are common for all ApplicationFactory(s)."
With
"The ApplicationFactory interface, as shown in Figure 7.40, provides the dynamic mechanism to create a specific type of Application (e.g.waveform) in the domain"
Remove Figure 7.39 - ApplicationFactory Capacity Overview
Add Figure 7.40 and title for 7.40 as follows
Figure.40 - ApplicationFactory Definition
Add title to Figure 7.42 as follows
"Figure 7.42 ApplicationFactory Capability Manager Relationships"
In sections 7.2.2.1.1.1 DomainEventChannels, 7.2.2.1.1.2 DomainInstallation, and 7.2.2.1.1.3 DeviceManagerRegistration replace figure reference from 7.27 to 7.28.
Actions taken:
March 24, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9581: PTT Signal De-Assertion (swradio-rtf)
Click here for this issue's archive.
Source: L-3 Communications, Communication Systems - West (Mr. Mark Scoville, mark.scoville@L-3com.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
April 21, 2006: received issue
April 19, 2007: closed no change
Discussion: 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
Issue 9582: Waveform Response to Audio Device RTS Signal (swradio-rtf)
Click here for this issue's archive.
Source: L-3 Communications, Communication Systems - West (Mr. Mark Scoville, mark.scoville@L-3com.com)
Nature: Uncategorized Issue
Severity:
Summary: 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?
Resolution:
Revised Text:
Actions taken:
April 21, 2006: received issue
Discussion: 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
Issue 9583: ConcreteDataPdu: New Attributes (swradio-rtf)
Click here for this issue's archive.
Source: L-3 Communications, Communication Systems - West (Mr. Mark Scoville, mark.scoville@L-3com.com)
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution:
Revised Text:
Actions taken:
April 21, 2006: received issue
Discussion: 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
Issue 9584: Stream / Channel - Parameters (swradio-rtf)
Click here for this issue's archive.
Source: L-3 Communications, Communication Systems - West (Mr. Mark Scoville, mark.scoville@L-3com.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
April 21, 2006: received issue
Discussion: 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
Issue 9585: SCA 2.2.x Backward Compatability (swradio-rtf)
Click here for this issue's archive.
Source: L-3 Communications, Communication Systems - West (Mr. Mark Scoville, mark.scoville@L-3com.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
April 21, 2006: received issue
April 19, 2007: closed no change
Discussion: 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
Issue 9610: DeviceManager Created Components Should Not Be Constrained (swradio-rtf)
Click here for this issue's archive.
Source: Boeing (Ms.Neli Hayes, persnaz.n.hayes@boeing.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
April 26, 2006: received issue
April 19, 2007: closed issue, no change
Discussion: Discussion:
No longer an issue. This flexibility is already in DeviceManagerComponent Semantics. Text from