Software Radio Components Avatar
  1. OMG Specification

Software Radio Components — Closed Issues

  • Acronym: SDRP
  • Issues Count: 171
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SDRP-187 Physical layer TBD needs to be fixed in the annex SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-186 Artifact Issues SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-184 LW Resource and Device Components SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-183 New Install Application Exception SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-185 Stereotypes Tables Inconsistencies SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-181 Enumeration Issues SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-180 Application Deployment Attributes SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-179 swradio Reference Section Issue SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-182 PIM and PSM for Radio Software Components SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-178 swradio Issue - Common and Data Link Layer Facilities SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-177 Missing Acknowledgements in SWRadio Spec SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-176 MAC Typo Issue SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-175 Consistent PIM Interface Name Issue SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-174 TestableObject Interface Runtest Operation Issue SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-173 Physical and IO facilities Location Issue SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-172 POSIX Profile Reference SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-171 Issue with Component Framework Spec SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-170 DeviceManager Created Components Should Not Be Constrained SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-169 SCA 2.2.x Backward Compatability SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-168 PTT Signal De-Assertion SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-167 PIM and PSM SWRadio Spec Figures Issue SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-166 AntennaElement SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-165 Oneway operation stereotype SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-163 ApplicationResourceComponent Definition SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-162 ServiceComponent Definition Issue SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-161 L.2.1 Software Package Desription SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-164 SWRadioComponent additional constraint SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-160 SAD ComponentInstantiation Description Error SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-157 Add Required and Provided ports definitions that are specialization of SWRa SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-156 Add other Descriptor Types SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-159 Add SAD CollocationProcess Element. SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-158 SAD FindComponent Cardinality Error SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-155 Make Descriptor and LoadableCode a parent of File. SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-154 ExecutableCode Constraint Missing SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-153 Code Artifact Manifest Constraint Missing SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-152 Application Stereotype Incomplete SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-151 Constant Interface Definitions Invalid SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-150 Missing type for loadKind property for loadabledevicecomponent SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-149 ConfigureProperty Errors SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-148 LoadableDeviceComponent CharacteristicSetProperties Definition Incomplete SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-147 Add CharacteristicSelectionType Type Constraint SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-146 LoadType Inconsistent SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-144 Port Not Defined SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-143 Object Type Not Defined. SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-142 PropertyValue Definition Incomplete SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-145 FileSystemComponent Constraint Missing SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-138 Invalid ServiceProperty’s capabilityModel attribute Type SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-141 Exception Definition Missing SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-140 Inconsistent use of the term "Facility or Facilities" SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-139 Flexibility to Perform Allocation, Load and Execute Behavior SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-124 Primitive Type Cleanup SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-123 Cardinality problem SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-122 IDL Scoping Rules SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-120 Service Typos in the Specification, UML Model, PSM, and IDL SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-119 ProcessIDType SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-121 CFCommonTypes.idl is missing definition of TimeType SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-118 Section 8.1.6.1.2 ExecutableDevice, Semantics SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-116 Section: Appendix H SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-117 Inconsistent Models between Fig. 9-57 and Fig. 9-60 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-114 Correction of Invalid References to Non-Existent Property Type SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-113 Issue: 8.1.2 Literal Specifications SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-115 Application releaseObject Disconnect Behavior SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-112 There are still some types not defined in the spec SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-111 Use of Float and Double types for CommEquip and PhysicalLayer Facilities SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-110 Time type definition more than once in spec SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-109 Lack of descriptor PSM definition SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-108 Issue 2. Continuation of Issue 7786 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-106 Clarify purpose of composite device SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-105 reword part of create behavior SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-104 registerDeviceManager description conflict SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-107 Issue 1. Continuation of Issue 7786 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-103 DM Install and Register Duplication Clarification SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-102 PIM and PSM for Software Radio Annex H issue 8 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-101 DomainManager::uninstallApplication should not require removal of files SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-100 PIM and PSM for Software Radio Annex H issue 7 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-99 PIM and PSM for Software Radio Annex H issue 6 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-98 PIM and PSM for Software Radio Annex H issue 5 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-97 PIM and PSM for Software Radio Annex H issue 4 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-96 PIM and PSM for Software Radio Annex H issue 3 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-95 PIM and PSM for Software Radio Annex H issue 2 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-93 Undefined Types SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-92 remove and replace obsolete DigitalConverter references SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-94 PIM and PSM for Software Radio Annex H issue 1 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-91 PSM out of sync with Facilities, 7725, 7787, and 7789 didn't update IDL SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-90 PIM and PSM for SWradio Components SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-89 Waveform Compliance Criteria SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-86 Common Radio Facilities SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-85 Property Enumeration SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-88 Compliance Clarification SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-87 Audio I/O Facilities Attribute Types SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-84 From 8.3.2.1, section Attributes SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-83 From 8.3.2.2, section Constrains SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-79 Configure & Query Property SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-82 From 8.3.2.6, section Associations SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-81 8.3.2.6, section Associations SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-80 8.3.2, section Description SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-78 TestProperty SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-77 Property clean up SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-76 Figure 9-78 - Radio Set Facilities Overview SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-75 multiple interfaces on a port SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-74 Factor out portExists() operation out of DomainManager and Devicemanager SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-73 ControllableController ambiguity SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-69 Lacking component definitions in IO Facilities Section (9.4 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-72 Stereotype Display Format SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-71 Unable able to express the direction of a port for a SWRadioComponent SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-70 PSM Names Not Unique SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-68 Remove any reference to IScheduling from the specification SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-67 PIM-PSM translation SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-66 Section 9.2.5.3 IPdu specialization SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-65 Section 9.3.1.4.1, IConnectionLink Operations SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-62 Correct the typos in the spec SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-64 ApplicationFactory SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-63 "WaveForm" and "Application" are not used consistantly SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-61 M1 and M2 data for the UML Profile for SWRadio SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-60 9.3.1.1.1 ILocalLinkManagement SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-57 9.3.1.2.1 ConnectionlessLink Component SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-59 AckReplyPdu definition SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-58 9.3.1.3.1 IAckConnectionless SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-56 9.3.1.1.1 ILocalLinkManagement SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-55 Irrelevant description SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-52 LogicalSecurityChannel SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-54 wrong semantics description SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-53 wrong reference throughout Section 8.3.3.1 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-51 I/O_Algorithm description SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-50 Description Section 8.3.2.4, pg 128 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-49 Invalid reference SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-48 Wrong section name SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-47 Name change Section 8.2.6.4.8, pg 114 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-46 Name change Section 8.2.6.4.7, pg 113 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-45 Name change Section 8.2.6.4.5, pg 111 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-42 Name change Section 8.2.6.4.2, pg 110 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-44 Name change Section 8.2.6.4.4, pg 111 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-43 Redundant class name Section 8.2.6.4.3, pg 110 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-41 Name change Section 8.2.6.4, pg 107 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-40 Missing attributes Section 8.2.6.3, pg 106 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-39 Missing constraint Section 8.2.6, pg 103 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-38 Missing stereotype descriptions SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-34 redundant Association Section 8.1.6.4, pg 88. SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-37 redundant Association Section 8.1.6.7, pg 91 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-36 redundant Association Section 8.1.6.6, pg 90 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-35 redundant Association Section 8.1.6.5, pg 89 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-33 Issue: Wrong name SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-30 Explanation of different port types SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-32 Missing reference to the figure SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-31 Missing explanation for invalid properties SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-29 Missing stereotype SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-25 Name problem SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-28 Model and description does not agree SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-27 Name problem Section 8.1.2.7, pg 51 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-26 Name problem section 8.1.2.6 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-23 Lack Consistent use of SWRadio Stereotypes in Facilities interface SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-22 inconsistent wording in ResourceComponents SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-24 Add definition for Properties SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-21 Add Properties CORBA PSM Definition SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-20 Lack Consistent use of SWRadio Stereotypes in Facilities interface SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-19 Port related interfaces SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-18 Facilities Parameter Modes and Type definitions SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-16 Typos and Acrynoms definitions missing in in section 9.5 SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-15 swradio issue primitive types SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-17 Section 9.2.4.2 IStatusSignal SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-14 Keep text constraint descriptions in addition to OCL as OCL is hard to read SDRP 1.0b1 SDRP 1.0 Duplicate or Merged closed
SDRP-13 Start/stop behavior SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-12 Replace expanded/duplicated IDL in CORBA modules with include statements SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-11 Lack of OCL Statements for constraints SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-10 Break the spec into multiple volumes SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-9 Specify which interfaces are mandatory SDRP 1.0b1 SDRP 1.0 Closed; No Change closed
SDRP-8 Lack of XML definition SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-7 file Service becomes part of the CF name space. SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-6 DisconnectPort operation SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-5 Obtaining resource provided interfaces during deployment SDRP 1.0b1 SDRP 1.0 Resolved closed
SDRP-4 A provided port can have multiple interfaces SDRP 1.0b1 SDRP 1.0 Resolved closed

Issues Descriptions

Physical layer TBD needs to be fixed in the annex

  • Key: SDRP-187
  • Legacy Issue Number: 7583
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:56 GMT

Artifact Issues

  • Key: SDRP-186
  • Legacy Issue Number: 10425
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Thu, 26 Oct 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

LW Resource and Device Components

  • Key: SDRP-184
  • Legacy Issue Number: 10421
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Mike Browne)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Fri, 20 Oct 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

New Install Application Exception

  • Key: SDRP-183
  • Legacy Issue Number: 10418
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 24 Oct 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Stereotypes Tables Inconsistencies

  • Key: SDRP-185
  • Legacy Issue Number: 10424
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Stereotypes Tables are missing text in constraints column.

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

  • Reported: SDRP 1.0b1 — Thu, 26 Oct 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Enumeration Issues

  • Key: SDRP-181
  • Legacy Issue Number: 10416
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Fri, 20 Oct 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Application Deployment Attributes

  • Key: SDRP-180
  • Legacy Issue Number: 10415
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Fri, 20 Oct 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

swradio Reference Section Issue

  • Key: SDRP-179
  • Legacy Issue Number: 9927
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Wed, 19 Jul 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

PIM and PSM for Radio Software Components

  • Key: SDRP-182
  • Legacy Issue Number: 10417
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 24 Oct 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

swradio Issue - Common and Data Link Layer Facilities

  • Key: SDRP-178
  • Legacy Issue Number: 9924
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 18 Jul 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Missing Acknowledgements in SWRadio Spec

  • Key: SDRP-177
  • Legacy Issue Number: 9919
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Thu, 13 Jul 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

MAC Typo Issue

  • Key: SDRP-176
  • Legacy Issue Number: 9918
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Thu, 13 Jul 2006 04:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Consistent PIM Interface Name Issue

  • Key: SDRP-175
  • Legacy Issue Number: 9916
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

TestableObject Interface Runtest Operation Issue

  • Key: SDRP-174
  • Legacy Issue Number: 9910
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Mon, 10 Jul 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Physical and IO facilities Location Issue

  • Key: SDRP-173
  • Legacy Issue Number: 9909
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Mon, 10 Jul 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

POSIX Profile Reference

  • Key: SDRP-172
  • Legacy Issue Number: 9616
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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)

  • Reported: SDRP 1.0b1 — Fri, 28 Apr 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Issue with Component Framework Spec

  • Key: SDRP-171
  • Legacy Issue Number: 9612
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Mike Browne)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Fri, 21 Apr 2006 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

DeviceManager Created Components Should Not Be Constrained

  • Key: SDRP-170
  • Legacy Issue Number: 9610
  • Status: closed  
  • Source: Engility ( Neli Hayes)
  • 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.

  • Reported: SDRP 1.0b1 — Wed, 26 Apr 2006 04:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

SCA 2.2.x Backward Compatability

  • Key: SDRP-169
  • Legacy Issue Number: 9585
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Mark Scoville)
  • 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.

  • Reported: SDRP 1.0b1 — Fri, 21 Apr 2006 04:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

PTT Signal De-Assertion

  • Key: SDRP-168
  • Legacy Issue Number: 9581
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Mark Scoville)
  • 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.

  • Reported: SDRP 1.0b1 — Fri, 21 Apr 2006 04:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

PIM and PSM SWRadio Spec Figures Issue

  • Key: SDRP-167
  • Legacy Issue Number: 9469
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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

  • Reported: SDRP 1.0b1 — Fri, 24 Mar 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

AntennaElement

  • Key: SDRP-166
  • Legacy Issue Number: 9350
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    AntennaElement. AntennaElement not in Communication Equipment Stereotype table

  • Reported: SDRP 1.0b1 — Wed, 1 Feb 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Oneway operation stereotype

  • Key: SDRP-165
  • Legacy Issue Number: 9348
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.

  • Reported: SDRP 1.0b1 — Wed, 1 Feb 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

ApplicationResourceComponent Definition

  • Key: SDRP-163
  • Legacy Issue Number: 9346
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    ApplicationResourceComponent Definition. ApplicationResourceComponent needs to a specialization of ResourceComponent

  • Reported: SDRP 1.0b1 — Wed, 1 Feb 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

ServiceComponent Definition Issue

  • Key: SDRP-162
  • Legacy Issue Number: 9336
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.

  • Reported: SDRP 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

L.2.1 Software Package Desription

  • Key: SDRP-161
  • Legacy Issue Number: 9335
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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”

  • Reported: SDRP 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

SWRadioComponent additional constraint

  • Key: SDRP-164
  • Legacy Issue Number: 9347
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Wed, 1 Feb 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

SAD ComponentInstantiation Description Error

  • Key: SDRP-160
  • Legacy Issue Number: 9334
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.”

  • Reported: SDRP 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Add Required and Provided ports definitions that are specialization of SWRa

  • Key: SDRP-157
  • Legacy Issue Number: 9331
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.

  • Reported: SDRP 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Add other Descriptor Types

  • Key: SDRP-156
  • Legacy Issue Number: 9317
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Fri, 27 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Add SAD CollocationProcess Element.

  • Key: SDRP-159
  • Legacy Issue Number: 9333
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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

  • Reported: SDRP 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

SAD FindComponent Cardinality Error

  • Key: SDRP-158
  • Legacy Issue Number: 9332
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    For the componentinstantiation element the findcomponent cardinality cannot be optional

  • Reported: SDRP 1.0b1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Make Descriptor and LoadableCode a parent of File.

  • Key: SDRP-155
  • Legacy Issue Number: 9316
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:
  • Reported: SDRP 1.0b1 — Fri, 27 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

ExecutableCode Constraint Missing

  • Key: SDRP-154
  • Legacy Issue Number: 9315
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    For ExecutableCode add a constraint on properties being executableproperty types

  • Reported: SDRP 1.0b1 — Fri, 27 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Code Artifact Manifest Constraint Missing

  • Key: SDRP-153
  • Legacy Issue Number: 9314
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.

  • Reported: SDRP 1.0b1 — Fri, 27 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Application Stereotype Incomplete

  • Key: SDRP-152
  • Legacy Issue Number: 9313
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.

  • Reported: SDRP 1.0b1 — Thu, 26 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Constant Interface Definitions Invalid

  • Key: SDRP-151
  • Legacy Issue Number: 9308
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.

  • Reported: SDRP 1.0b1 — Wed, 25 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Missing type for loadKind property for loadabledevicecomponent

  • Key: SDRP-150
  • Legacy Issue Number: 9307
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

ConfigureProperty Errors

  • Key: SDRP-149
  • Legacy Issue Number: 9306
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

LoadableDeviceComponent CharacteristicSetProperties Definition Incomplete

  • Key: SDRP-148
  • Legacy Issue Number: 9305
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Add CharacteristicSelectionType Type Constraint

  • Key: SDRP-147
  • Legacy Issue Number: 9304
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

LoadType Inconsistent

  • Key: SDRP-146
  • Legacy Issue Number: 9303
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Port Not Defined

  • Key: SDRP-144
  • Legacy Issue Number: 9301
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Object Type Not Defined.

  • Key: SDRP-143
  • Legacy Issue Number: 9299
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

PropertyValue Definition Incomplete

  • Key: SDRP-142
  • Legacy Issue Number: 9298
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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.

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

FileSystemComponent Constraint Missing

  • Key: SDRP-145
  • Legacy Issue Number: 9302
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Invalid ServiceProperty’s capabilityModel attribute Type

  • Key: SDRP-138
  • Legacy Issue Number: 8988
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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”

  • Reported: SDRP 1.0b1 — Thu, 15 Sep 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Exception Definition Missing

  • Key: SDRP-141
  • Legacy Issue Number: 9297
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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

  • Reported: SDRP 1.0b1 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Inconsistent use of the term "Facility or Facilities"

  • Key: SDRP-140
  • Legacy Issue Number: 9231
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Mark Scoville)
  • 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.

  • Reported: SDRP 1.0b1 — Thu, 8 Dec 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Flexibility to Perform Allocation, Load and Execute Behavior

  • Key: SDRP-139
  • Legacy Issue Number: 9229
  • Status: closed  
  • Source: Engility ( Neli Hayes)
  • 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.

  • Reported: SDRP 1.0b1 — Tue, 6 Dec 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:33 GMT

Primitive Type Cleanup

  • Key: SDRP-124
  • Legacy Issue Number: 7895
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 21 Sep 1999 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:30 GMT

Cardinality problem

  • Key: SDRP-123
  • Legacy Issue Number: 7698
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:30 GMT

IDL Scoping Rules

  • Key: SDRP-122
  • Legacy Issue Number: 8981
  • Status: closed  
  • Source: RTX ( Mr. Roy M. Bell)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Service Typos in the Specification, UML Model, PSM, and IDL

  • Key: SDRP-120
  • Legacy Issue Number: 8950
  • Status: closed  
  • Source: Engility ( Neli Hayes)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Wed, 3 Aug 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

ProcessIDType

  • Key: SDRP-119
  • Legacy Issue Number: 8949
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

CFCommonTypes.idl is missing definition of TimeType

  • Key: SDRP-121
  • Legacy Issue Number: 8980
  • Status: closed  
  • Source: RTX ( Mr. Roy M. Bell)
  • Summary:

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

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

    { /* This value corresponds to POSIX time_t type */ long seconds; long nanoseconds; }

    ;

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

  • Reported: SDRP 1.0b1 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Section 8.1.6.1.2 ExecutableDevice, Semantics

  • Key: SDRP-118
  • Legacy Issue Number: 8948
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Section: Appendix H

  • Key: SDRP-116
  • Legacy Issue Number: 8934
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Inconsistent Models between Fig. 9-57 and Fig. 9-60

  • Key: SDRP-117
  • Legacy Issue Number: 8943
  • Status: closed  
  • Source: SCA Technica, Inc. ( Shereef Sayed)
  • Summary:

    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?

  • Reported: SDRP 1.0b1 — Thu, 7 Jul 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Correction of Invalid References to Non-Existent Property Type

  • Key: SDRP-114
  • Legacy Issue Number: 8873
  • Status: closed  
  • Source: Engility ( Neli Hayes)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Fri, 24 Jun 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Issue: 8.1.2 Literal Specifications

  • Key: SDRP-113
  • Legacy Issue Number: 8872
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Mon, 27 Jun 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Application releaseObject Disconnect Behavior

  • Key: SDRP-115
  • Legacy Issue Number: 8931
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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"

  • Reported: SDRP 1.0b1 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

There are still some types not defined in the spec

  • Key: SDRP-112
  • Legacy Issue Number: 8871
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Fri, 24 Jun 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Use of Float and Double types for CommEquip and PhysicalLayer Facilities

  • Key: SDRP-111
  • Legacy Issue Number: 8870
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Fri, 24 Jun 2005 04:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Time type definition more than once in spec

  • Key: SDRP-110
  • Legacy Issue Number: 8869
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Fri, 24 Jun 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Lack of descriptor PSM definition

  • Key: SDRP-109
  • Legacy Issue Number: 8868
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

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

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

  • Reported: SDRP 1.0b1 — Fri, 24 Jun 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Issue 2. Continuation of Issue 7786

  • Key: SDRP-108
  • Legacy Issue Number: 8858
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Mon, 6 Jun 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Clarify purpose of composite device

  • Key: SDRP-106
  • Legacy Issue Number: 8842
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

reword part of create behavior

  • Key: SDRP-105
  • Legacy Issue Number: 8841
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

registerDeviceManager description conflict

  • Key: SDRP-104
  • Legacy Issue Number: 8840
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Issue 1. Continuation of Issue 7786

  • Key: SDRP-107
  • Legacy Issue Number: 8857
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Mon, 6 Jun 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

DM Install and Register Duplication Clarification

  • Key: SDRP-103
  • Legacy Issue Number: 8839
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 8

  • Key: SDRP-102
  • Legacy Issue Number: 8838
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

DomainManager::uninstallApplication should not require removal of files

  • Key: SDRP-101
  • Legacy Issue Number: 8837
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 7

  • Key: SDRP-100
  • Legacy Issue Number: 8836
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 6

  • Key: SDRP-99
  • Legacy Issue Number: 8835
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 5

  • Key: SDRP-98
  • Legacy Issue Number: 8834
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 4

  • Key: SDRP-97
  • Legacy Issue Number: 8833
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 3

  • Key: SDRP-96
  • Legacy Issue Number: 8832
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 2

  • Key: SDRP-95
  • Legacy Issue Number: 8831
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Undefined Types

  • Key: SDRP-93
  • Legacy Issue Number: 8519
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Mark Scoville)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Mon, 7 Mar 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

remove and replace obsolete DigitalConverter references

  • Key: SDRP-92
  • Legacy Issue Number: 8344
  • Status: closed  
  • Source: zeligsoft.com ( John Hogg)
  • Summary:

    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
  • Reported: SDRP 1.0b1 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for Software Radio Annex H issue 1

  • Key: SDRP-94
  • Legacy Issue Number: 8830
  • Status: closed  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 May 2005 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PSM out of sync with Facilities, 7725, 7787, and 7789 didn't update IDL

  • Key: SDRP-91
  • Legacy Issue Number: 8296
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Thu, 17 Feb 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM and PSM for SWradio Components

  • Key: SDRP-90
  • Legacy Issue Number: 8291
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Wed, 16 Feb 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Waveform Compliance Criteria

  • Key: SDRP-89
  • Legacy Issue Number: 8259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Common Radio Facilities

  • Key: SDRP-86
  • Legacy Issue Number: 8201
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Property Enumeration

  • Key: SDRP-85
  • Legacy Issue Number: 8200
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Compliance Clarification

  • Key: SDRP-88
  • Legacy Issue Number: 8251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Audio I/O Facilities Attribute Types

  • Key: SDRP-87
  • Legacy Issue Number: 8205
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

From 8.3.2.1, section Attributes

  • Key: SDRP-84
  • Legacy Issue Number: 8125
  • Status: closed  
  • Source: SCA Technica, Inc. ( Tony Martin)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

From 8.3.2.2, section Constrains

  • Key: SDRP-83
  • Legacy Issue Number: 8124
  • Status: closed  
  • Source: SCA Technica, Inc. ( Tony Martin)
  • Summary: {communication channel requires at least one of an RF channel or an I/O channel}

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

    Proposed Solutions:
    Rework the constraint to read as:

    {LogicalCommunicationChannel requires at least one of a SecureLogicalCommunicationChannel, LogicalPhysicalChannel, LogicalIOChannel, or LogicalProcessingChannel.}
  • Reported: SDRP 1.0b1 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Configure & Query Property

  • Key: SDRP-79
  • Legacy Issue Number: 7985
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Thu, 16 Dec 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

From 8.3.2.6, section Associations

  • Key: SDRP-82
  • Legacy Issue Number: 8123
  • Status: closed  
  • Source: SCA Technica, Inc. ( Tony Martin)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

8.3.2.6, section Associations

  • Key: SDRP-81
  • Legacy Issue Number: 8122
  • Status: closed  
  • Source: SCA Technica, Inc. ( Tony Martin)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

8.3.2, section Description

  • Key: SDRP-80
  • Legacy Issue Number: 8121
  • Status: closed  
  • Source: SCA Technica, Inc. ( Tony Martin)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

TestProperty

  • Key: SDRP-78
  • Legacy Issue Number: 7984
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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)

  • Reported: SDRP 1.0b1 — Thu, 16 Dec 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Property clean up

  • Key: SDRP-77
  • Legacy Issue Number: 7983
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Thu, 16 Dec 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Figure 9-78 - Radio Set Facilities Overview

  • Key: SDRP-76
  • Legacy Issue Number: 7959
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

multiple interfaces on a port

  • Key: SDRP-75
  • Legacy Issue Number: 7953
  • Status: closed  
  • Source: zeligsoft.com ( John Hogg)
  • Summary:

    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.

  • Reported: SDRP 1.0b1 — Tue, 30 Nov 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Factor out portExists() operation out of DomainManager and Devicemanager

  • Key: SDRP-74
  • Legacy Issue Number: 7905
  • Status: closed  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

    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

  • Reported: SDRP 1.0b1 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

ControllableController ambiguity

  • Key: SDRP-73
  • Legacy Issue Number: 7904
  • Status: closed  
  • Source: prismtech.com ( Dominick Paniscotti)
  • Summary:

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

    Proposed Solution:

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

  • Reported: SDRP 1.0b1 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Lacking component definitions in IO Facilities Section (9.4

  • Key: SDRP-69
  • Legacy Issue Number: 7868
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: IO Facilities section Rose model defines a SerialIODeviceComponent and an AudioIODeviceComponent, but these components are never specified in the document.

    Proposed resolution: Create new subsections as 9.4.1.2 SerialIODeviceComponent and 9.4.2.2 AudioIODeviceComponent. specify which interfaces need to be realized and which ports are required.

  • Reported: SDRP 1.0b1 — Mon, 18 Oct 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Stereotype Display Format

  • Key: SDRP-72
  • Legacy Issue Number: 7898
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

  • Reported: SDRP 1.0b1 — Tue, 2 Nov 2004 05:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Unable able to express the direction of a port for a SWRadioComponent

  • Key: SDRP-71
  • Legacy Issue Number: 7888
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

    Add new section

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

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

    Types & Exceptions

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

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

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

  • Reported: SDRP 1.0b1 — Fri, 29 Oct 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PSM Names Not Unique

  • Key: SDRP-70
  • Legacy Issue Number: 7878
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

    Proposed Solution

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

    Updated Facilities and PSM based upon name changes.

  • Reported: SDRP 1.0b1 — Thu, 21 Oct 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Remove any reference to IScheduling from the specification

  • Key: SDRP-68
  • Legacy Issue Number: 7849
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Fri, 8 Oct 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

PIM-PSM translation

  • Key: SDRP-67
  • Legacy Issue Number: 7845
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Thu, 7 Oct 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Section 9.2.5.3 IPdu specialization

  • Key: SDRP-66
  • Legacy Issue Number: 7789
  • Status: closed  
  • Source: Anonymous
  • Summary:

    DESCRIPTION:
    IPdu interface should specialize the IFlowControlSignalling interface
    and not the IFlowControlManagement interface.

    PROPOSED RESOLUTION:
    In Section 9.2.5.3, (IPdu) pg 202, replace the following sentence:
    "IPdu interface also specializes IFlowControl interface, so it supports
    flow controlling."

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

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

  • Reported: SDRP 1.0b1 — Wed, 29 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Section 9.3.1.4.1, IConnectionLink Operations

  • Key: SDRP-65
  • Legacy Issue Number: 7787
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    PROPOSED RESOLUTION:
    Change the following operation descriptions from:

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

    to:

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

  • Reported: SDRP 1.0b1 — Wed, 29 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Correct the typos in the spec

  • Key: SDRP-62
  • Legacy Issue Number: 7781
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Thu, 23 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

ApplicationFactory

  • Key: SDRP-64
  • Legacy Issue Number: 7786
  • Status: closed  
  • Source: Engility ( Neli Hayes)
  • Summary:

    ApplicationFactory Should Provide the Option for Directly Configuring ApplicationResourceComponents

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

    Proposed Solution:

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

    from

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

    to

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

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

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

    Rationale:

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

  • Reported: SDRP 1.0b1 — Mon, 27 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

"WaveForm" and "Application" are not used consistantly

  • Key: SDRP-63
  • Legacy Issue Number: 7785
  • Status: closed  
  • Source: Rockwell Collins ( David Fitkin)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Fri, 24 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

M1 and M2 data for the UML Profile for SWRadio

  • Key: SDRP-61
  • Legacy Issue Number: 7742
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

  • Reported: SDRP 1.0b1 — Mon, 13 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

9.3.1.1.1 ILocalLinkManagement

  • Key: SDRP-60
  • Legacy Issue Number: 7729
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    PIM and PSM Software Radio Components

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

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

    getInfo(in connectionID : ConnectionIDType, return InfoType):

    {raises = (InvalidPort, SystemError)}

    This operation requests information of the provider about the currently
    established connection. The connectionID parameter identifies a stream
    (defined as a user connected to the provider). The operation may raise
    the InvalidPort exception or SystemError exception.

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

  • Reported: SDRP 1.0b1 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

9.3.1.2.1 ConnectionlessLink Component

  • Key: SDRP-57
  • Legacy Issue Number: 7726
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

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

  • Reported: SDRP 1.0b1 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

AckReplyPdu definition

  • Key: SDRP-59
  • Legacy Issue Number: 7728
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

  • Reported: SDRP 1.0b1 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

9.3.1.3.1 IAckConnectionless

  • Key: SDRP-58
  • Legacy Issue Number: 7727
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

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

  • Reported: SDRP 1.0b1 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

9.3.1.1.1 ILocalLinkManagement

  • Key: SDRP-56
  • Legacy Issue Number: 7725
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

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

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

  • Reported: SDRP 1.0b1 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Irrelevant description

  • Key: SDRP-55
  • Legacy Issue Number: 7720
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

LogicalSecurityChannel

  • Key: SDRP-52
  • Legacy Issue Number: 7717
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

wrong semantics description

  • Key: SDRP-54
  • Legacy Issue Number: 7719
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

wrong reference throughout Section 8.3.3.1

  • Key: SDRP-53
  • Legacy Issue Number: 7718
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

I/O_Algorithm description

  • Key: SDRP-51
  • Legacy Issue Number: 7716
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Description Section 8.3.2.4, pg 128

  • Key: SDRP-50
  • Legacy Issue Number: 7715
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Invalid reference

  • Key: SDRP-49
  • Legacy Issue Number: 7714
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Wrong section name

  • Key: SDRP-48
  • Legacy Issue Number: 7713
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name change Section 8.2.6.4.8, pg 114

  • Key: SDRP-47
  • Legacy Issue Number: 7712
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name change Section 8.2.6.4.7, pg 113

  • Key: SDRP-46
  • Legacy Issue Number: 7711
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name change Section 8.2.6.4.5, pg 111

  • Key: SDRP-45
  • Legacy Issue Number: 7710
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name change Section 8.2.6.4.2, pg 110

  • Key: SDRP-42
  • Legacy Issue Number: 7707
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name change Section 8.2.6.4.4, pg 111

  • Key: SDRP-44
  • Legacy Issue Number: 7709
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Redundant class name Section 8.2.6.4.3, pg 110

  • Key: SDRP-43
  • Legacy Issue Number: 7708
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name change Section 8.2.6.4, pg 107

  • Key: SDRP-41
  • Legacy Issue Number: 7706
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Missing attributes Section 8.2.6.3, pg 106

  • Key: SDRP-40
  • Legacy Issue Number: 7705
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Missing constraint Section 8.2.6, pg 103

  • Key: SDRP-39
  • Legacy Issue Number: 7704
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Missing stereotype descriptions

  • Key: SDRP-38
  • Legacy Issue Number: 7703
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 20:53 GMT

redundant Association Section 8.1.6.4, pg 88.

  • Key: SDRP-34
  • Legacy Issue Number: 7699
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

redundant Association Section 8.1.6.7, pg 91

  • Key: SDRP-37
  • Legacy Issue Number: 7702
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

redundant Association Section 8.1.6.6, pg 90

  • Key: SDRP-36
  • Legacy Issue Number: 7701
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

redundant Association Section 8.1.6.5, pg 89

  • Key: SDRP-35
  • Legacy Issue Number: 7700
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Issue: Wrong name

  • Key: SDRP-33
  • Legacy Issue Number: 7697
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Explanation of different port types

  • Key: SDRP-30
  • Legacy Issue Number: 7694
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Missing reference to the figure

  • Key: SDRP-32
  • Legacy Issue Number: 7696
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Missing explanation for invalid properties

  • Key: SDRP-31
  • Legacy Issue Number: 7695
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Missing stereotype

  • Key: SDRP-29
  • Legacy Issue Number: 7693
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name problem

  • Key: SDRP-25
  • Legacy Issue Number: 7689
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Model and description does not agree

  • Key: SDRP-28
  • Legacy Issue Number: 7692
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name problem Section 8.1.2.7, pg 51

  • Key: SDRP-27
  • Legacy Issue Number: 7691
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Name problem section 8.1.2.6

  • Key: SDRP-26
  • Legacy Issue Number: 7690
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Lack Consistent use of SWRadio Stereotypes in Facilities interface

  • Key: SDRP-23
  • Legacy Issue Number: 7684
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 7 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

inconsistent wording in ResourceComponents

  • Key: SDRP-22
  • Legacy Issue Number: 7672
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

  • Reported: SDRP 1.0b1 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Add definition for Properties

  • Key: SDRP-24
  • Legacy Issue Number: 7688
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Add Properties CORBA PSM Definition

  • Key: SDRP-21
  • Legacy Issue Number: 7662
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Wed, 25 Aug 2004 04:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Lack Consistent use of SWRadio Stereotypes in Facilities interface

  • Key: SDRP-20
  • Legacy Issue Number: 7661
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    PIM and PSM for Software Radio Spec

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

  • Reported: SDRP 1.0b1 — Wed, 25 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Port related interfaces

  • Key: SDRP-19
  • Legacy Issue Number: 7660
  • Status: closed  
  • Source: Spectrum Signal Processing, Inc. ( Geoff Holt)
  • Summary:

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

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

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

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

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

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

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

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

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

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

  • Reported: SDRP 1.0b1 — Tue, 24 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Facilities Parameter Modes and Type definitions

  • Key: SDRP-18
  • Legacy Issue Number: 7658
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    PIM and PSM Software Radio Components Spec Issue

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

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

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

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

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

  • Reported: SDRP 1.0b1 — Mon, 23 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Typos and Acrynoms definitions missing in in section 9.5

  • Key: SDRP-16
  • Legacy Issue Number: 7656
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    PIM and PSM Software Radio Components Specification

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

  • Reported: SDRP 1.0b1 — Mon, 23 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

swradio issue primitive types

  • Key: SDRP-15
  • Legacy Issue Number: 7655
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

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

  • Reported: SDRP 1.0b1 — Mon, 23 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Section 9.2.4.2 IStatusSignal

  • Key: SDRP-17
  • Legacy Issue Number: 7657
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    PIM and PSM Software Radio Spec Issue

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

  • Reported: SDRP 1.0b1 — Mon, 23 Aug 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

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

  • Key: SDRP-14
  • Legacy Issue Number: 7596
  • Status: closed  
  • Source: Blue Collar Objects ( Camille Bell)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Wed, 21 Jul 2004 04:00 GMT
  • Disposition: Duplicate or Merged — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Start/stop behavior

  • Key: SDRP-13
  • Legacy Issue Number: 7588
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Wed, 14 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Replace expanded/duplicated IDL in CORBA modules with include statements

  • Key: SDRP-12
  • Legacy Issue Number: 7587
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Wed, 14 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Lack of OCL Statements for constraints

  • Key: SDRP-11
  • Legacy Issue Number: 7586
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Wed, 14 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Break the spec into multiple volumes

  • Key: SDRP-10
  • Legacy Issue Number: 7585
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Specify which interfaces are mandatory

  • Key: SDRP-9
  • Legacy Issue Number: 7584
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Closed; No Change — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Lack of XML definition

  • Key: SDRP-8
  • Legacy Issue Number: 7582
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

file Service becomes part of the CF name space.

  • Key: SDRP-7
  • Legacy Issue Number: 7581
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

DisconnectPort operation

  • Key: SDRP-6
  • Legacy Issue Number: 7580
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

Obtaining resource provided interfaces during deployment

  • Key: SDRP-5
  • Legacy Issue Number: 7579
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT

A provided port can have multiple interfaces

  • Key: SDRP-4
  • Legacy Issue Number: 7578
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

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

  • Reported: SDRP 1.0b1 — Tue, 13 Jul 2004 04:00 GMT
  • Disposition: Resolved — SDRP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:53 GMT