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

No Data Available

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

No Data Available

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

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

Specifically:

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

Add constraints to the effect that:

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

Add Device Component constraints to the effect that:

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

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

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

No Data Available

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

Proposed Resolution:

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

No Data Available

Stereotypes Tables are missing text in constraints column.

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

No Data Available

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

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

No Data Available

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

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

No Data Available

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

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

No Data Available

Issues:

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

Proposed Resolution

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

No Data Available

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

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

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

Resolution: Some of the changes are as follows:

1. Eliminate Duplicate Type definitions,

2.make figure and text agree,

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

4. rename FlowControlSignalling to FlowControlSignaling

5. Add missing types, InfoType, etc.

6. Make TransitDelay a TimeType.

No Data Available

PIM and PSM for SW Radio Components

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

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

No Data Available

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

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

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

No Data Available

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

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

OMG Issue No: 7661

Title: Lack Consistent use of SWRadio Stereotypes in Facilities interface

Source:

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

Summary:

The specification lacks consistent use of the SWRadio stereotypes for the interface definitions in the Facilities. Section 8.1.3 defines the stereotypes for ports and interfaces that are to be used for the definition of the facilities or components in the section 9.

Resolution:

Replace <<interface>> stereotype with the correct corresponding interface stereotype as described in section 8.1.3. Also the interface names that start with "I" in the name should be removed to consistent too. The interface stereotypes have the "I" in their names

No Data Available

PIM and PSM for Software Radio Components Spec

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

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

No Data Available

PIM and PSM Software Radio Spec

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

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

No Data Available

The POSIX profile is based upon the 1998 standard.

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

Resolution

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

No Data Available

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

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

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

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

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

AntennaElement. AntennaElement not in Communication Equipment Stereotype table

No Data Available

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

No Data Available

ApplicationResourceComponent Definition. ApplicationResourceComponent needs to a specialization of ResourceComponent

No Data Available

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.

No Data Available

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”

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

For the componentinstantiation element the findcomponent cardinality cannot be optional

No Data Available

No Data Available

For ExecutableCode add a constraint on properties being executableproperty types

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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”

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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

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

No Data Available

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

No Data Available

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

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

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

No Data Available

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

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

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

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

Proposed Solution:

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

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

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

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

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

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

No Data Available

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

Change ProcessIDType from Ulong to Long for ExecutableDevice interface
definition

No Data Available

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

I did not find TimeType defined in the SCA IDL, but I did find the following definition in the SCA LogService.idl file:
struct LogTimeType

;

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

No Data Available

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

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

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

No Data Available

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

No Data Available

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

Resolution: I'm not sure.

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

No Data Available

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

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

Rationale: Correctness and removal of redundant information

No Data Available

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

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

In the rose model, change the specialization relationship to extension

No Data Available

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

Rational:

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

ApplicationManager Semantics

from

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

to

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

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

No Data Available

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

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

No Data Available

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

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

Examples frequency, meter, etc.

No Data Available

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

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

Change radioProperty's integerId type from string to Unsigned short

No Data Available

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

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

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

No Data Available

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

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

see above

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

Rationale: Clarify composite behavior.

No Data Available

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

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

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

No Data Available

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

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

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

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

No Data Available

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

No Data Available

Section 8.3.3.1.1.3, Device Manager registration, add the following text

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

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

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

ApplicationAlreadyInstalled

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

exception ApplicationAlreadyInstalled{};

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

Make corresponding changes to the IDL.

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

No Data Available

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

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

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

Rationale: Improve the accuracy of the specification

No Data Available

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

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

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

No Data Available

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

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

No Data Available

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

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

Rationale: correctness

No Data Available

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

NOTE:
NRQ - Not required for this profile.

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

NOTE:
NRQ - Not required for this profile.

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

NOTE:
NRQ - Not required for this profile.

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

NOTE:
NRQ - Not required for this profile.

Rationale: Specification Correctness

No Data Available

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

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

No Data Available

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

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

No Data Available

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

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

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

No Data Available

Undefined Types

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

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

2. Radiation: Information about a specific radiation environment.

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

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

No Data Available

Proposed Solution:

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

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

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

No Data Available

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

No Data Available

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

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

No Data Available

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

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

No Data Available

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

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

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

No Data Available

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

No Data Available

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

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

No Data Available

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

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

No Data Available

Verify that the audio types are correct as being float.

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

No Data Available

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

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

No Data Available

There is neither a description of a "RF channel" nor a "communication
channel" in the specification.

Proposed Solutions:
Rework the constraint to read as:

No Data Available

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

Proposed Solutions
8.1.2 Properties Section

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

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

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

No Data Available

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

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

No Data Available

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

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

No Data Available

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

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

No Data Available

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

Proposed Solutions
8.1.2 Properties Section

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

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

(Embedded image moved to file: pic09040.jpg)

No Data Available

Issue 1 - Property clean up

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

Proposed Solutions
8.1.2 Properties Section

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

No Data Available

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

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

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

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

No Data Available

Problem:
Ports can have multiple provided and multiple required interfaces. This complicates transforming a PIM to a CORBA PSM and encourages questionable architectures. It is also confusing to implementers and users as shown by issues 7578 and 7579.

Proposed solution:
Constrain ports in the SWRadio PIM and PSM to have at most one provided interface and one required interface per port.

No Data Available

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

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

No Data Available