Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2004 Mercury Computer Systems, Inc. Overview of Recent Advances in SDR Standardization “SDR for Everyone” A. Tansu Demirbilek, Dr. Jeffrey E. Smith–

Similar presentations


Presentation on theme: "© 2004 Mercury Computer Systems, Inc. Overview of Recent Advances in SDR Standardization “SDR for Everyone” A. Tansu Demirbilek, Dr. Jeffrey E. Smith–"— Presentation transcript:

1 © 2004 Mercury Computer Systems, Inc. Overview of Recent Advances in SDR Standardization “SDR for Everyone” A. Tansu Demirbilek, Dr. Jeffrey E. Smith– Mercury Computer Systems Dr. Jean Belzile – Ecole de Technologie Superieure David Roberge – ISR Technologies

2 © 2004 Mercury Computer Systems, Inc. 2 What does this tutorial offer? An overview of: l Recent advances in SDR community l Current enabling technologies and state of art l Where SDR standards are evolving l What is meant by “SDR for everyone”

3 © 2004 Mercury Computer Systems, Inc. 3 Agenda 1.Introduction 1.SDR Background 2.Ongoing SDR Standardization Activities 3.JTRS SCA 2.Enabling Technologies 1.UML 2.Component Based Distributed Applications 3.Model Driven Architecture 4.Heterogeneous Processing Platforms

4 © 2004 Mercury Computer Systems, Inc. 4 Agenda 3.OMG Software Radio Standard 1.Introduction 2.UML Profile 3.Platform Independent Model 4.Platform Specific Model

5 © 2004 Mercury Computer Systems, Inc. Section 1.1 “SDR Background”

6 © 2004 Mercury Computer Systems, Inc. 6 What is SDR? l Acronym for “Software Defined Radio” Provides: Interoperability Reconfigurability Portability of component based waveform applications l Promises achieved by “Software Communications Architecture”, mandated by the Army’s Joint Program Office (JPO)

7 © 2004 Mercury Computer Systems, Inc. 7 High-Speed Switch Fabric RF/IF A/D & D/A Security Message Processing Antenna Interface ccc d dd Control Bus Control Interface BLACK Control Interface Link Processing Modem c d Software Modem Adaptive Proc. d c RED Software Radio Functional Architecture

8 © 2004 Mercury Computer Systems, Inc. 8 Why SDR? Multi-Billion Dollar Market for … An SDR terminal can be used for any wireless communication by downloading new software An SDR base station can communicate with any kind of terminal (i.e. Cellular, Telephone, PDA) by downloading new software

9 © 2004 Mercury Computer Systems, Inc. 9 Why SDR? l The rapid pace of technological advances render communications devices obsolete shortly after production l Interoperability is needed between devices that are implemented in different technologies l Increasing traffic rates and decreasing amounts of spectrum require more sophisticated signal processing algorithms

10 © 2004 Mercury Computer Systems, Inc. 10 SDR Goals l Interoperability of different SDR systems l Portability of applications software between different SDR implementations l Upgradeability in terms of easy technology insertion l Reduced development time of new waveforms through the ability to reuse design modules l Reduced system acquisition, operation and supportability costs l ANSWER: Standard Interfaces (APIs)

11 © 2004 Mercury Computer Systems, Inc. Section 1.2 “Ongoing SDR Activities”

12 © 2004 Mercury Computer Systems, Inc. 12 Ongoing SDR Activities l GLOMO (Not active anymore) l OBSAI (www.obsai.org) l CPRI (www.cpri.info) l Digital IF (www.digitalif.org) l SDRF (www.sdrforum.org) l SCA (jtrs.army.mil) l OMG Specs (www.omg.org)

13 © 2004 Mercury Computer Systems, Inc. Section 1.3 “JTRS Software Communications Architecture”

14 © 2004 Mercury Computer Systems, Inc. 14 Software Communications Architecture l An open, standard, well-defined architecture l Component based approach to waveforms l Improves interoperability by sharing waveform components between radios l Supports multiple domains and multiple bands l Increases operational flexibility l Maximizes independence of software from hardware l Provide upgradeability with easy technology insertion and capability upgrades l Extendible to new waveforms and hardware

15 © 2004 Mercury Computer Systems, Inc. 15 SCA Components HCI Hardware OS (function) that supports SCA Core Framework: Framework Control & Framework Service Interface CORBA ORB and Services Waveform XMLBinary SCA Interfaces (UML/IDL) Application Environment Profile

16 © 2004 Mercury Computer Systems, Inc. 16 SCA Structural Details l Specifies APIs to support distributed applications for flexible, re-programmable communication capabilities l Specifies a common framework to build-up, configure, connect and tear-down distributed, embedded radio applications l The SCA has been structured to: wProvide for portability of applications software between different SCA implementations wLeverage commercial standards to reduce development cost wReduce development time of new waveforms through reuse of design modules wBuild on evolving commercial frameworks and architectures l Designed to meet commercial and military application requirements

17 © 2004 Mercury Computer Systems, Inc. 17 Joint Tactical Radio System (JTRS) DefinitionSCA 1.0SCA 2.0SCA 2.1SCA 2.2SCA X…n SCA Foundation Software Defined Radio Forum (SDRF) (Approx. 130 members) Object Management Group (OMG) (approx. 800 Int’l members) < 2 MHz2 MHz – 2 Ghz 2 - 6 GHz Cluster 1 (Ground Vehicle, Helicopters) Cluster 2/5 (Handheld, Manpack, Embed) Cluster 3 (Maritime/Fixed site) Cluster 4 (Airborne) Subsurface Space 6–15/55 GHz and beyond Homeland Security Source: JTRS JPO, Joint Program Status Update, 30 June 2003

18 © 2004 Mercury Computer Systems, Inc. 18 Software Radio Standards Working Groups SCA Software Radio DSIG SCA TAG/CCB

19 © 2004 Mercury Computer Systems, Inc. 19 Business Model JTeL Primer by SPAWAR

20 © 2004 Mercury Computer Systems, Inc. 20 SCA Evolution l Now: SCA is a fairly large specification covering broad aspects of a system wHard to have commercial implementations wHard to control evolution of the spec l Future: SCA has been sliced into pieces for OMG standardization w“OMG Suite of Specs” wSWRadio, D&C, Lw CCM, Lw Log, Lw Services

21 © 2004 Mercury Computer Systems, Inc. Section 2 “Enabling Technologies”

22 © 2004 Mercury Computer Systems, Inc. 22 Enabling Technologies Overview l UML l Component Based Distributed Applications l Heterogeneous Processing Platforms l MDA

23 © 2004 Mercury Computer Systems, Inc. Section 2.1 “UML”

24 © 2004 Mercury Computer Systems, Inc. 24 What is UML l UML = “Unified Modeling Language” l Graphical modeling language l Does not specify design methodology wRational Unified Process (RUP) developed as one methodology for using UML wSuccessor to many Object Oriented (OO) Design & Analysis methods l Standardized by the OMG

25 © 2004 Mercury Computer Systems, Inc. 25 What is UML used for? l Provides a common language for functional specifications wNatural language is not precise enough wCode is too detailed l Highlight important details wProvide overall view of a system l Logical decomposition of large projects wFocus on details without losing overall goals wSeparate implementation task into parts wBuild individually testable components

26 © 2004 Mercury Computer Systems, Inc. 26 UML Diagram Hierarchy UML PackageUse CaseStructure Class Component Behavior Activity Interaction CollaborationInteraction State Sequence Deployment

27 © 2004 Mercury Computer Systems, Inc. 27 How is it used? l Graphical notation to communicate design wDiagrams highlight particular aspect of design l Assist in communication wCustomer wOther developers l Documentation of design process l CASE tools wCode generation wReverse engineering wCode merging

28 © 2004 Mercury Computer Systems, Inc. 28 What does it look like?

29 © 2004 Mercury Computer Systems, Inc. Section 2.2 “Component Based Distributed Applications”

30 © 2004 Mercury Computer Systems, Inc. 30 What’s the idea? The idea is simple: l If we build the parts of our system to well- defined specification, then it should be easy to assemble these pieces to create a system l It should also be relatively easy to replace one part of a system with another part that meets the same specification, after the system is built

31 © 2004 Mercury Computer Systems, Inc. 31 What’s new? l This doesn’t sound so new!? Even in 1995. wBut “well-defined” enough to “easily assemble” requires more specification than an interface in a header file at compile time! wTrue replaceability (plug & play) requires last-moment and fine-grained linkages between pieces of software wAssembly out of parts from different sources requires a new way to describe and deploy the software wNone of this is accomplished with “object oriented languages” or “client/server systems”.

32 © 2004 Mercury Computer Systems, Inc. 32 What’s a component? l A software package which offers services through interfaces l A reusable part that provides the physical packaging of implementation elements l An independently deliverable package of software operations that can be used to build applications or larger components l A unit of software that is pre-built, packaged, self-describing, which can be individually deployed or updated or replaced in the field. It can be sent as an email attachment

33 © 2004 Mercury Computer Systems, Inc. 33 Component Packaging IDL/CIDL Compiler User Code Generated Code IDL Component Descriptor Default Configuration Compiler Shared Library or Executable Packaging Tool Component Package.zip “Engineering” CIDL

34 © 2004 Mercury Computer Systems, Inc. 34 Component Assembly “Manufacturing” Configuration Values Deployment Tool Assembly Archive.aar (ZIP) Assembly Tool Component Package Component Package Component Package Port Connections Instance Creation...

35 © 2004 Mercury Computer Systems, Inc. 35 Related OMG Specifications l CORBA wDistributed system, middleware l CORBA Component Model (CCM) wBased on CORBA wComponent Model, Component Implementation Definition Language, Container Programming Model, Packaging and Deployment l Deployment & Configuration wBased on CCM wDeployment system, assemblies

36 © 2004 Mercury Computer Systems, Inc. Section 2.3 “Model Driven Architecture”

37 © 2004 Mercury Computer Systems, Inc. 37 What is MDA? l “Model Driven Architecture” l Defines a software lifecycle that minimizes duplicate efforts l Enables mappings between Platform Independent Models (PIM), Platform Specific Models (PSM) to actual code l Crucial for SDR technology where portability is a big issue

38 © 2004 Mercury Computer Systems, Inc. 38 MDA Concepts CORBA IDL (Language) UML (Language) Meta-Language Transformation PSM in CORBA IDL PIM in UML Transformation Tool

39 © 2004 Mercury Computer Systems, Inc. Section 2.4 “Heterogeneous Processing Platforms”

40 © 2004 Mercury Computer Systems, Inc. 40 SCA Compliant Radios Component-Centric Architecture Customer Application Application Environment Component Middleware Processing Resource (NATO Waveform) Adapter for Specific Tool Kit to Component Middleware Mercury Component Middleware Object-Oriented Application Environment And API Tool Kit (SCA) SW Components SW Drivers Embedded RISC, DSP, FPGA ASIC, Sensor I/O, etc. Software defined handsets Layered approach maximizes COTS content and use of legacy equipment Hardware transparent to software Air-programmable Vendor independent

41 © 2004 Mercury Computer Systems, Inc. 41 Heterogeneous Radio Architecture Pool of Processors Slice – based Radio System No bounds on processor usage Scale to zero Dynamic rescheduling Load balancing Number of waveforms limited Waveform complexity limited Not reconfigurable No load balancing

42 © 2004 Mercury Computer Systems, Inc. 42 Memory Buffer 1 Memory Buffer N Platform Architecture Container A Container B Comp A Comp B Memory Buffer N Memor y Buffer 1............ Mercury Fabric Fabric handles congestion management and priority based routing Middleware provides transparent communication

43 © 2004 Mercury Computer Systems, Inc. Section 3 “OMG Software Radio Activities ”

44 © 2004 Mercury Computer Systems, Inc. 44 SWRadio OMG l Work at Software Based Communication (SBC) Domain Task Force (DTF) of the OMG l Lead by Mercury, Raytheon and Thales l Effort to convert SCA into a commercial standard by recasting it as an OMG standard like CORBA, UML, etc. l Final submission will be voted for adoption at the April ’04 OMG meeting in St. Louis this week l Will likely become new mandate for future procurements (SCA 3.0?) l Will be more broadly acceptable outside JTRS and outside DoD

45 © 2004 Mercury Computer Systems, Inc. 45 Next Generation SCA l Morphing into an OMG form, as an umbrella spec of standards l Each change go through the TAG in order to be a part of SCA l Advantage: Leverage existing and emerging specifications wIncrease COTS content in SCA specification wInherit advanced features (e.g. Component Model, heterogeneous deployment) Lightweight Services Lightweight CCM Deployment and Configuration Lightweight Logging SCA Personality COTS Content SCA NG

46 © 2004 Mercury Computer Systems, Inc. 46 Next Generation SCA l SCA already points to existing standards such as DLPI, POSIX l SCA is getting more lightweight by pointing to open OMG specifications RTOS ORB SCA RTOS ORB SCA - NG D&C LCCM SWRadio

47 © 2004 Mercury Computer Systems, Inc. Section 3.1 “Design Rationale ”

48 © 2004 Mercury Computer Systems, Inc. 48 SWRadio Specification l MDA based approach wUML Profile for SWRadio Domain wPlatform Independent Model (PIM) wPlatform Specific Model (PSM) for CORBA, XML wTransformation mechanism for PIM to PSM mapping l Several compliance points wWaveform developer wInfrastructure developer wTool developer

49 © 2004 Mercury Computer Systems, Inc. 49 Design Rationale

50 © 2004 Mercury Computer Systems, Inc. 50 Design Rationale, cont’d 1. 2.

51 © 2004 Mercury Computer Systems, Inc. 51 Conformance Criteria Waveform application Waveform applications PSM Waveform applications PIM SWRadio infrastructureSWR Infra- structure PSM SWR Infra- structure PIM Model of SWRadio components Satisfies all constraints of profile package SWRadio tool Simple: Supports profile constructs in and UML 2 XMI exchange mechanism CORBA/XML-based: Supports Profile-WaveformPIM and PIM-PSM mappings and conformant waveform apps. Conformant on the part of a:If: Implements CORBA interfaces defined by: Conformance to XML serialization formats defined by: Implements semantics defined by:

52 © 2004 Mercury Computer Systems, Inc. 52 SWRadio Products Overview

53 © 2004 Mercury Computer Systems, Inc. Section 3.2 “UML Profile ”

54 © 2004 Mercury Computer Systems, Inc. 54 UML Profile l Defines a language for specifying SWRadio elements (HW & SW) l Organized according to 3 viewpoints: Application and device developers –Application and Device Components SWRadio platforms providers –Communication Equipment Infrastructure and middleware providers –Infrastructure l Standardize interfaces and components Enable COTS SWRadio development.

55 © 2004 Mercury Computer Systems, Inc. 55 Applications and Devices l Set of component and interface stereotype definitions used for the development of applications, logical devices, and components. wBase Types –basic types String, octet, exceptions… wProperties –stereotypes for configure, query, testable, service artifact (capability and capacity) and executable properties wResource Components – stereotypes for interfaces and components of the ResourceComponent. wDevice Components –stereotypes for the logical device components that represent devices. wApplication Components – defines stereotypes for the ResourceComponents.

56 © 2004 Mercury Computer Systems, Inc. 56 CommEquipment Package l SWRadio ≡ Computer wThis is represented in the basic classes

57 © 2004 Mercury Computer Systems, Inc. 57 Modeling Concepts l Key concepts wProperties Express fundamental attribute of element Used by software to learn about or configure element wPorts Use to collect the properties related to the interconnections wDevices Used to collect the properties related to the devices Can have an arbitrary number of ports Capable of intelligence

58 © 2004 Mercury Computer Systems, Inc. 58 Properties l CharacteristicProperty wIndicates a static and non- queryable attribute. wConstraints based on physics limitations. Impedance, Noise figure, Size, Weight, Max, Min,… l QueryProperty wIndicates a queryable but non- configurable attribute. wConstraints that may change but not by software. Operating environment, RAM size, Temperature,… l ConfigureProperty wIndicates a dynamic attribute. wConstraint usually associated with an API. Frequency response, Gain, Center frequency,…

59 © 2004 Mercury Computer Systems, Inc. 59 Ports Information exchange between devices. wModeling of entire transmission and reception chains. wAnalog ports for analog signal input/output. VSWR, Power handling, Impedance,… wDigital ports for digital signal input/output. Throughput, Quantization noise,…

60 © 2004 Mercury Computer Systems, Inc. 60 SWRadio Products Overview

61 © 2004 Mercury Computer Systems, Inc. 61 Infrastructure Package l Defines the language to specify software components, services and applications within a radio infrastructure for SWRadio applications, and to manage the radio’s domain, services, and devices. l This set of stereotypes includes RadioManager, DeviceManager, Application, and ApplicationFactory components.

62 © 2004 Mercury Computer Systems, Inc. 62 Infrastructure Package l Domain Registration Management wProvides the mechanism for registering and unregistering services within a radio. l Domain Installation Management wProvides the mechanism for installing and uninstalling applications within a radio. l Domain Retrieval wProvides the mechanism for retrieving radio’s components. l Domain Event Management wProvides the mechanism for receiving asynchronous radio’s domain event changes. Radio Management - Domain

63 © 2004 Mercury Computer Systems, Inc. 63 Infrastructure Package l Service Registration Management wProvides the mechanism for registering and unregistering services within a node. l Node Retrieval wProvides the mechanism for retrieving radio’s node components. Radio Management - Node

64 © 2004 Mercury Computer Systems, Inc. 64 Infrastructure Package wMiddleware services Event service Naming service wFramework services OS environment File service Installer service Log service wMore to come from SBC DTF wRadio services Cosite service GPS service Fault management service Measurement service Preset service Retransmission service Scanner service Platform Services l Stereotypes representing SWRadio platform services.

65 © 2004 Mercury Computer Systems, Inc. 65 Infrastructure Package l Interface to the OMG Deployment & Configuration spec l Stereotypes required to deploy services and applications l Executable artifacts wApplications and waveforms wLogical devices wServices Deployment

66 © 2004 Mercury Computer Systems, Inc. 66 UML Profile Summary l Simple but powerful l Flexible but manageable l Attains its objectives: wAbility to model the physical components of a communication equipment. wProvide a set of parameters to check for compatibility between waveform and platform. wCapture platform requirements wAbility to model and simulate a SWRadio. l Future: wCommercial block set tools?

67 © 2004 Mercury Computer Systems, Inc. Section 3.3 “Platform Independent Model”

68 © 2004 Mercury Computer Systems, Inc. 68 SWRadio Products Overview

69 © 2004 Mercury Computer Systems, Inc. 69 Platform Independent Model l Objective wProvide PIM interfaces that waveform applications use across all platforms. wProvide PIM interfaces that software radio infrastructures supply as standard facilities wDefine example component definitions that realize the specified interfaces to provide SWRadio services l Independent from: wDistributed component middlewares (CORBA,.NET) wProgramming languages (C++, Java) wInformation formatting technologies (XML)

70 © 2004 Mercury Computer Systems, Inc. 70 Platform Independent Model l Strategy wSignal processing APIs according to OSI Model. wControl and management APIs span across all Layers wCreate ‘common layer’ and ‘common radio’ groupings l Viewpoints wSoftware Radio Infrastructure - defines interfaces & architecture wWaveform Application Components – specifies waveform related interfaces l Potential usage wProvides coherent and standard APIs for waveform portability. wSpecifies clean interfaces for simulation packages.

71 © 2004 Mercury Computer Systems, Inc. 71 PIM for Waveform Layering l Link wLLC and MAC l Physical wModem, IF/RF, IO l Common wQoS, Flow control, Measurement, Error control, PDU, Stream l Management wConfigure and get status wControl communication channels

72 © 2004 Mercury Computer Systems, Inc. 72 Platform Independent Model - PIM l Defines the SDR system model following the OSI layers l Independent of implementation details (WHAT, NOT HOW) l Defines common APIs for waveform applications l Consists of packages: w Common Layer Facilities w Common Radio Facilities w Data Link Layer Facilities w I/O Facilities w Physical Layer Facilities w Radio Control Facilities

73 © 2004 Mercury Computer Systems, Inc. 73 Common Layer Facilities Package Interfaces that cross-cut through waveform layers

74 © 2004 Mercury Computer Systems, Inc. 74 Common Radio Facilities Package l File Facilities wFile system wFile management wFiles l Scheduling Facility wTimers and scheduling certain events

75 © 2004 Mercury Computer Systems, Inc. 75 Link Layer Control (LLC) Facilities Package l Defines the LLC facilities as a part of Data Link Layer l Based on the DLPI spec l Provides facilities for wLocal Management wConnectionless Link wAck Connectionless Link wConnection Oriented Link l Reuses some of the common layer facilities

76 © 2004 Mercury Computer Systems, Inc. 76 Example ConnectionlessLink Component

77 © 2004 Mercury Computer Systems, Inc. 77 MAC Layer Facilities Package l Defines interactions between a MAC Layer user (service user) and a MAC Layer (service provider) l List of facilities populated after a long waveform survey l Several facilities include: wTransec wChannel Access wQoS wMAC addressing etc.

78 © 2004 Mercury Computer Systems, Inc. 78 I/O Facilities Package l Acknowledges the fact that I/O can occur at every waveform layer. l Defines the configuration properties for Audio and Serial Facilities l Contains several interfaces wVirtual resource Control wDevice Control wSecurity control wFlow Control

79 © 2004 Mercury Computer Systems, Inc. 79 Physical Layer Facilities Package l Interfaces on both control and data planes l Used to control the communication equipment device attributes defined in the UML Profile l Partitioned into: wModem Facilities wRF/IF Facilities

80 © 2004 Mercury Computer Systems, Inc. 80 Radio Control Facilities Package l Alarms and Alerts l Radio Management Facility w Management of the radio (domain management) wManagement of devices and services within a radio (device management)

81 © 2004 Mercury Computer Systems, Inc. 81 Conclusion – PIM l Provides waveform portability through standard software interfaces Organized as in OSI model l Does not require layered implementation l Coherent with key characteristics of UML model l Can be extended to create vertical I/O models

82 © 2004 Mercury Computer Systems, Inc. 82 SWRadio Products Overview

83 © 2004 Mercury Computer Systems, Inc. Section 3.4 “Platform Specific Model”

84 © 2004 Mercury Computer Systems, Inc. 84 Platform Specific Model l Automatic PSM generation from PIM and profile definitions l Platform Specific to wCORBA wXML wPOSIX l Other PSMs could be defined (J2EE,.NET, etc.)

85 © 2004 Mercury Computer Systems, Inc. 85 Summary l Provides the infrastructure to deploy and host Software Radio components. l Provides a set of services and facilities that represent typical Communication device functionality. l SBC DTF (and other interested groups) will continue to enhance the suite of available services and facilities. wWorking on the submission for over year wHas the backing of many supporters wBased upon existing specifications l Forms the basis for the upcoming SBC workshop this September

86 © 2004 Mercury Computer Systems, Inc. Thanks! A. Tansu Demirbilek Dr. Jean Belzile David Roberge

87 © 2004 Mercury Computer Systems, Inc. Section 4 “Backup Slides”

88 © 2004 Mercury Computer Systems, Inc. 88 GLoMo l Stands for “Global Mobile Information Systems “ l A Past DARPA initiative l Defines standard interfaces for communicating between algorithm components l Specifies a hardware infrastructure l Experimential l Not a standard

89 © 2004 Mercury Computer Systems, Inc. 89 & & l OBSAI – Open Base Station Architecture Initiative l CPRI – Common Public Radio Interface l Led by Base Station vendors l Both define a standard 3G Base Station Architecture for plug-and- play HW/SW module capability.

90 © 2004 Mercury Computer Systems, Inc. 90 Digital IF l Led by Mercury Computer Systems, Inc. l Defines standard hardware and software interfaces and the physical link between tuners and processing platforms

91 © 2004 Mercury Computer Systems, Inc. 91 l A vendor-neutral consortium led by the SDR community activists l Issues recommendations on SDR specifications l Issues RFI for reference implementations (SCARI – SCA v2.2 Reference Implementation)

92 © 2004 Mercury Computer Systems, Inc. 92 SCA l “Software Communications Architecture” l Non-Proprietary Specification Sponsored by the Joint Tactical Radio System (JTRS) program l Current version is 2.2 (jtrs.army.mil) l Change by Technical Advisory group (TAG) and Change Control Board (CCB)

93 © 2004 Mercury Computer Systems, Inc. 93 l Open membership, not-for-profit organization l Produces and maintains freely available computer industry specifications l Commercial industry implements specs as COTS Software (e.g CORBA, D&C, CCM) l Software Based Communication DTF and SWRadio DSIG specifying new standards based on SCA 2.2

94 © 2004 Mercury Computer Systems, Inc. 94 OMG RFPs Schedule shaded areas indicate completed task * “Three week rule”

95 © 2004 Mercury Computer Systems, Inc. 95 Class Diagram l Provides overview of system l Defines software classes wAttributes wOperation signatures l Shows relationships between classes wUses wExtends wRealizes

96 © 2004 Mercury Computer Systems, Inc. 96 Use Case Diagrams l Use case represents a set of actions in the system l Actors are objects outside the system that communicate with it l Diagram shows how use cases interact with actors l Details of a use case can be specified by text or as a sequence diagram.

97 © 2004 Mercury Computer Systems, Inc. 97 Sequence Diagram l Interactive diagram l Shows interactions of actors and objects l Provides details of an operation or use case wWho starts the operation wHow performed wMessages sent l Organized according to time wProgresses as it moves down the page wShow relationship of operations to time

98 © 2004 Mercury Computer Systems, Inc. 98 State Diagram l State defined by activity or condition l Diagram shows wPossible states of an object wConditions that cause state change l Focus on object changing between discrete states

99 © 2004 Mercury Computer Systems, Inc. 99 Activity Diagram l Fancy flowchart wSeparate actions by entity l Related to state diagram l Focus on flow of activity to complete a process

100 © 2004 Mercury Computer Systems, Inc. 100 Connecting the Pieces

101 © 2004 Mercury Computer Systems, Inc. 101 UML Key Points l Technical communication language wRead documents written by developers wRead technical articles published in journals l Shows opportunities for component reuse l Benefits of modeling before coding l Write documentation for future maintenance of designed product

102 © 2004 Mercury Computer Systems, Inc. 102 Fundamentals l Component-based software has become a buzzword since mid ’90’s. l “The industrialization of software delivery” l OO technologies provide the technical framework l The contract of a component defines wDeployment dependencies wInterfaces wHow the component can be deployed, instantiated l Explicit context dependencies wSpecification of deployment environment w“Bridges” to other component worlds

103 © 2004 Mercury Computer Systems, Inc. 103 What’s a component? l Defined for its “users” by: wPorts that provide a service via an interface/protocol (component acting as server) wPorts that require (use) a service via an interface/protocol (component acting as client) wConfiguration (instantiation) parameters. wAn overall functional behavior l Packaged as a combination (e.g. zip archive) of compiled code files (e.g. DLLs) and descriptive metadata (e.g. XML). l Metadata allows tools and runtime environments to know how to use it, configure, run it, after it is compiled and packaged. Ports that require a service Ports that provide service Component Definition Component Package (e.g. ZIP file) Definition Metadata Implementation Metadata Compiled Code Config params: - Color: red (default)

104 © 2004 Mercury Computer Systems, Inc. 104 Component-based Development Environment l Components l Assemblies wBuilt from components wConnections between the ports of components wMay be hierarchical (an assembly can be a component) wExpressed as metadata l Containers wExecution environment for components wProvides for communication between components wMay have multiple per computer for different component types (Java, C++) l Distributed system wCollection of computers with containers wThe target of deployment for component-based applications l Deployment system wRuns applications on a distributed system wTalks to all the containers wMay decide how/where to run all the components wDeals with packaged components, and software distribution

105 © 2004 Mercury Computer Systems, Inc. 105 Typical Case l System Engineers wDesign & simulate the system using scientific simulation tools w(Possibly) Model the system using UML wDocument the requirements l Software Engineers wRead the requirements wDevelop code from scratch wRe-develop the code every time it needs to be ported

106 © 2004 Mercury Computer Systems, Inc. 106 Model Driven Architecture (MDA) l Provides a software development life-cycle that can be automated for code-generation l Code generation is the end goal l UML is used as the modeling language PIMPSM Code Mapping 1 Mapping 2 Syste m Modeling

107 © 2004 Mercury Computer Systems, Inc. 107 How? l MDA provides suite of specs for those transformations to happen l Meta Object Facility (MOF) is a Meta Language that any language can be formally represented l XML Metadata Interchange (XMI) or CORBA Interface Definition Language (IDL) allows interchange of models between languages l Unified Modeling Language (UML) is a MOF based visual language for defining models

108 © 2004 Mercury Computer Systems, Inc. 108 MOF Meta-Language Concept MODELLANGUAGE META LANGUAGE Written in l A model can be written in any language l A language can be represented in MOF format, as a formal language l Transformations exist between formally represented languages, as well as models written in those languages

109 © 2004 Mercury Computer Systems, Inc. 109 Language Transformation l Envision UML model as the PIM language and the CORBA Interface Definition Language (IDL) as the PSM language l Define a transformation from UML to CORBA IDL, which has now been represented by meta-language elements CORBA IDL (Language) UML (Language) Meta-Language Transformation

110 © 2004 Mercury Computer Systems, Inc. 110 Defining the Language Transformation l Common API definitions are needed l An official transformation definition language is not there yet. MOF QVT (Query – View – Transformation) spec is still in the works. 5 teams are competing for the spec.

111 © 2004 Mercury Computer Systems, Inc. 111 Model Transformation Tool l Once the language transformation is defined, a model transformation tool should be developed to carry out the actual transformation l Considering the non-standard internal data representation of UML CASE tools, first an XML Schema (using XMI) should be created from the PIM l This XML Schema can be transformed using the model transformation tool.

112 © 2004 Mercury Computer Systems, Inc. 112 Intercomponent/Interprocessor Comm Timing Container A Container B Each container has a single processing element Components with different timing requirements can run on different containers

113 © 2004 Mercury Computer Systems, Inc. 113 Intercomponent/Interprocessor Comm Timing Container A Container B Comp A Runs once every 20ms Each execution takes 8ms

114 © 2004 Mercury Computer Systems, Inc. 114 Intercomponent/Interprocessor Comm Timing Container A Container B Comp A

115 © 2004 Mercury Computer Systems, Inc. 115 Intercomponent/Interprocessor Comm Timing Container A Container B Comp A Comp B Runs once every 2ms Each execution takes 1.2ms

116 © 2004 Mercury Computer Systems, Inc. 116 Intercomponent/Interprocessor Comm Timing Container A Container B Comp A Comp B

117 © 2004 Mercury Computer Systems, Inc. 117 Memory Buffer 1 Memory Buffer N Intercomponent/Interprocessor Comm Timing Container A Container B Comp A Comp B Memory Buffer N Memor y Buffer 1............ Multiple memory buffers enable components to run independently, without waiting for buffers to fill


Download ppt "© 2004 Mercury Computer Systems, Inc. Overview of Recent Advances in SDR Standardization “SDR for Everyone” A. Tansu Demirbilek, Dr. Jeffrey E. Smith–"

Similar presentations


Ads by Google