# Kiến trúc phần mềm Radio P11

Chia sẻ: Tien Van Van | Ngày: | Loại File: PDF | Số trang:37

0
63
lượt xem
8

## Kiến trúc phần mềm Radio P11

Mô tả tài liệu

Software Architecture Tradeoffs This chapter addresses software design for SDR nodes. This includes software functions, hardware-software interactions, object-oriented design, and software architecture. It also addresses the evolution of the software components of SDR designs. Architecture tradeoffs addressed include the partitioning of software into objects. The boundaries of functional-interfaces and levels of abstraction determine the potential for reuse. These boundaries also determine the ease with which software products from different development teams will integrate into a multi-mode SDR....

Chủ đề:

Bình luận(0)

Lưu

## Nội dung Text: Kiến trúc phần mềm Radio P11

2. 348 SOFTWARE ARCHITECTURE TRADEOFFS Figure 11-1 Top-level radio node architecture. added daily. The current commercial emphasis on wireless mobile computing and Internet access is producing software components for reuse. Corporate experience invariably includes one or more baseline systems with components that management envisions as potentially reusable whether they were designed for such reuse or not. Therefore, software follows a hybrid of top-down and bottom-up design. The top-down aspect identifies the behaviors and top-level partitioning of SDR software into objects. The bottom-up aspect identifies existing software components that may be encapsulated into objects at some appropriate level of abstraction to avoid the work of designing, coding, and testing those components again. The functional model of Figure 11-1 is the basis for the partitioning of software into components. This model was derived by examining hardware- software partitions of SDR technology-pathfinders and precursor systems. Software functional entities and associated top-level interfaces have exhib- ited strong consistency over time and across implementations by different teams. The functional model is therefore the top-down framework. The pro- cess iterates between top-down and bottom-up aspects to yield software objects organized into a class hierarchy. II. TOP-DOWN, OBJECT-ORIENTED DESIGN Top-down SDR software design is presented in this section. A. Object-Oriented Design for SDR This section further explains OOT principles introduced earlier. The aspects of OO design that support top-down software development in-
3. TOP-DOWN, OBJECT-ORIENTED DESIGN 349 Figure 11-2 Partial object model of a simple modem. clude encapsulation, message passing, property inheritance, and polymor- phism. 1. Encapsulation The first step in the development of object-oriented mod- els, whether for modeling, simulation, or software development, is the identi- fication of the object classes. This is accomplished by drawing a conceptual circle around a cohesive set of data and functions to define an object. Initially, one treats the entire radio node as an object in order to define its behaviors when stimulated by the external world. This encapsulates the entire system including software as one object. Subsequently, one defines the constituent software objects of which the radio node is comprised. A consistent set of software objects constitutes one of the radio’s personalities. These lower-level objects provide the well-known radio functions of filtering, modulation, de- modulation, timing and control, as well as objects that handle protocol stacks and user interfaces. The software objects should encapsulate groups of func- tions in ways that make sense to radio engineers, to promote object reuse and technology insertion. The Modem class illustrated in Figure 11-2 provides a convenient example. Encapsulated object classes within the modem interact with each other to accomplish modem tasks by exchanging messages. 2. Message Passing When a radio application sends a message to the Modem object to “modulate a baseband bitstream,” it is effectively executing a proce- dure call of the Modem object’s Modulate( ) method. To do this, the calling ob- ject executes Modem.Modulate( ), sometimes noted as Modem " Modulate( ). Early OO languages like LISP Machine LISP employed explicit message pass-
4. 350 SOFTWARE ARCHITECTURE TRADEOFFS ing using syntax like Send(Modem, Modulate(bits)). This sent the Modem ob- ject a request to modulate bits. Contemporary OO languages like Java employ the more concise message Modem.Modulate(bits). Message passing permits conceptually simple integration of software com- ponents. It also facilitates interconnections across physical boundaries of ASICs, FPGAs, DSPs, and GP processors. Layering includes the process of translating messages from one format to another. Tunneling includes the pro- cess of setting up a software path to a hardware entity. The driver software encapsulates the hardware by making public methods available to other objects in the system. In addition, interrupt service routines and interprocess communication typ- ically is based on message passing using the distributed processing approach. This has nothing to do with object-oriented design. On the other hand, the historical use of message passing in distributed processing makes it easy to encapsulate a processor as a software object. One may thus jointly address the needs of distributed multithreaded multiprocessing and object-oriented soft- ware by message passing. The path of transformations of a message defines a thread, in this framework. The clear, “public” definition of the messages—syntax and semantics—is necessary for the successful integration of software and hardware. Types of messages useful in object interfaces include: # Setup and control, # State and state transitions, # Information streams (an infinite sequence of messages of a specific for- mat), with specified timing constraints, # Timing and frequency-standard information, # INFOSEC information such as the current level of protection on each channel, # Operational parameters like hardware and software signal gain (which impacts linearity), and # Resource needs and capabilities (e.g., for plug-and-play). A data dictionary that includes the format (syntax) and meaning (semantics) of the messages should provide examples of when to and when not to use a given message. A comprehensive data dictionary also includes names for at least the public slots and methods of all objects in the system. The degree of “publicity” required is determined by the scope of the software components. If only new, locally designed software objects are to be used, then teamwide agreement on slots and messages suffices. If objects from multiple teams are to be used, then the agreement has to embrace all the teams. In particular, if the purpose of an SDR architecture is to engage all of industry in the creation of third-party products, then the data dictionary of messages should be part of the open architecture standard.
7. TOP-DOWN, OBJECT-ORIENTED DESIGN 353 Figure 11-3 Illustrative context diagram. The air interface, network management interface, and operational network interface provide access to external objects like subscribers and networks. Abstract external objects like callers and networks are called actors in UML terminology. Actors have properties and/or behaviors that shape the system design. Between the MTSO and each external system there are two arcs, one for each direction of stimulus and response, which are modeled as message- passing. The air interface represents the MTSO’s connection to the mobile subscribers. In this case messages include traffic channels and control chan- nels. In contemporary digital air interfaces such as GSM and IS-95 (CDMA), virtual channels are multiplexed over physical channels. There also may be channels for establishing timing (e.g., CDMA pilot channels) in a complex array of streams. From these, isochronous traffic channels (message streams) and formatted control packets (messages) must be recovered. The context diagram identifies all signal flows, data flows, and control flows with external entities. Signal flows are isochronous streams. Data flows contain near-real-time data packets. Control flows shift processor use among software objects. These flows may be defined in part by air-interface stan- dards. Specific designs invariably introduce nuances, such as the application- specific use of air-interface bits that the air-interface standards leave unspec- ified. 2. Event Lists The context diagram is examined for external events that may stimulate the system. Applicable messages from the air interface, status re- quests from the telecommunications management network (TMN), and calls placed through Signaling System 7 (SS7) from the PSTN are examples of external events. Each must elicit an appropriate response from the software. For each external event, there may be more than one system response. These are collected into a comprehensive event-response list.
8. 354 SOFTWARE ARCHITECTURE TRADEOFFS Figure 11-4 Layered context with event lists. From the usual object-oriented design perspective, one builds the software objects that recognize the external events and generate the required responses. For SDR applications, this enumeration of external events and system re- sponses must be tempered by considering the interface layers. These are mech- anisms through which the outside world imposes on the radio constraints of external events and responses that give rise to events unanticipated in the initial analysis. The layered context illustrated in Figure 11-4 includes the radio prop- agation environment, which adds noise and interference. Interference may cre- ate false messages and may mask legitimate messages from subscribers. This interaction is taken into account by expanding the external-events list. One may establish positive acknowledgment across the air interface with timeouts and back-off mechanisms to ensure that a masked message cannot cause a permanent suspended state of a critical resource like a traffic channel. Reception and transmission events might include pointing a smart antenna to maintain high CIR on a specific subscriber. In addition, the reception/ transmission layer will constrain some interfaces to observe the demanding timing requirements of the Synchronous Digital Hierarchy (SDH) or SS7. On the other hand, the Interfaces layer may provide some hardware relief to the software challenges. SDH products, for example, include T and E carrier chip and board-level interfaces. These meet many of the SDH requirements provided the SDR fills buffers fast enough (but not so fast as to overflow). Having examined these context layers for events that may not have been present in the initial context diagram, one defines an initial set of software objects. 3. Use-Case Scenarios The event lists contain stimulus response pairs among actors. It is instructive to trace the path of such pairs through the system.
14. 360 SOFTWARE ARCHITECTURE TRADEOFFS TABLE 11-1 Characteristics of Radio Software Objects Radio Objects Object Methods and Slots Antenna and RF Control (ARC) TX/RX, Power, Polarization Channel Control (CC) Allocate Resources, Configure, State Machines Waveform Processor (WP) Generation, Timing, Fault Detection, Mod/Demod INFOSEC Control (IC) Key, Control Bridge to Black Side, Authenticate INFOSEC Processing (IP) Encrypt, Decrypt, TRANSEC System Control (SC) Initialize/Shutdown, Test, System Status User Interface (UI) Commands and Displays Speech Processing (SP) Echo Cancellation, Voice Coding Protocol Processing (PP) Packetization, Routing, VGC Modems Each of these high-level object classes has a fine-structure which ultimate- ly consists of primitive single-function radio objects like filters, modulators, interleaving, clock recovery, bit-decision objects, etc. The protocol and speech processing objects implement protocol stacks such as ATM, TCP/IP, Mobile IP, etc. Consequently, internetworking to the wireline infrastructure consists of a few relatively monolithic/predefined (e.g., COTS) software ob- jects. Continuing with Figure 11-9, it is clear that the top-level objects of the software radio strongly reflect the characteristics of the hardware. Nodes organized around such objects exhibit the behaviors summarized in Table 11-1. B. SPEAKeasy I Software Architecture The SPEAKeasy I system was developed in Ada according to DoD criteria for software quality. Accordingly, the lowest-level Ada packages are generally small—less than 100 lines of code (with a couple of notable exceptions such as built-in-test). The SPEAKeasy I software system as built consists of the modules described in Table 11-2. Like any other software suite built on a schedule, the as-build code has some strong features—such as the handling of timing and the real-time performance —and some weak ones. Since an Ada implementation was mandated, there is no real-time executive except the Ada run-time kernel and library. In addition, the state machines were apparently hand-coded. Such code is less reusable than a Z.100 SDL equivalent. The degree of reverse engineering required to understand the code varies from package to package as a function of the style of the programmer. As a result, some packages had redundant comments such as $A = B + C; Add B and C together to get A$, when it would have been more helpful to say “The net timing offset, A, is the sum of the base system time, B, and the network offset, C.” Nevertheless, studying as-built code reveals design patterns.