Definition of Reactive Systems using the Waveform Description Language

1. Definition of Reactive Systems using the Waveform Description Language E.D.Willink, Racal Research Limited,Ed.Willink@rrl.co.uk, http://www.rrl.co.uk/projects/wdl/wdl.htmlSDR Forum and AFRL/IFGWaveform Development Environment Workshop,1st November 2000, UK Programmable Digital Radio (PDR) Phase 1, Waveform Description Language (WDL) programme (DERA contract CU009-0000002745)Raytheon, Communication Systems Division, Fort Wayne, Indiana, Racal, Racal Research Limited, England

2. Introduction • WDL and Specifications • Examples (from FM3TR) • Architectural Mapping (JTRS) • Summary

3. WDL Antecedents

4. Specification or Implementation • Implementation • How it can be done • Specification • What needs to be done • Waveform Description Language (WDL) • Implementation practices re-applied in the specification domain • One specification • Many alternate implementations

5. WDL Products

6. Specification of Systems and Subsystems • subsystems exist at many scales • telecomms - international / national / regional / local / internal • equipment - cabinet / rack / module / board / component • CORBA components support two scales • inside • outside • WDL • fully encapsulated • same approach at all scales • WDL specifies without implementing • WDL may be refined from a specification to an implementation

7. Specification of Communication • High level systems • sporadic control events • Low level systems • intensive calculation • ‘continuous’ communication • WDL • sporadic and continuous flows are supported • continuous and discrete time are interchangeable

8. Complete specification (Low Level) • Amplifier - relatively easy • vout = 10 * vin • In practice need constraints • frequency < 1 GHz • load impedance 50 Ω ± 10% • third harmonic ... • WDL • mathematical definition of the ideal behaviour • constraints to bound permitted behaviour

9. Complete specification (High Level) • System specifications - very challenging • large, unreadable • Informal specification • terse - omissions lead to ambiguities • verbose - duplications lead to contradictions • Formal specification • good in principle • impractical for real applications • unapproachable for most practitioners • WDL • pragmatic compromise • formalisable, modular, familiar, practical, acceptable

10. Specification in WDL • Progressive decomposition • systems - subsystems - components - building blocks • Single hierarchical perspective • clear readable specification • removes ambiguities, avoids contradictions • Implementation in WDL • Progressive refinement of specification • further decomposition • practical constraints • recomposition • Minimal refinement • executable reference model

11. WDL Transformations

12. WDLRefinement

13. Refinement • Abstract WDL specification (unimplementable) • Waveform sponsor refines to support • a reference model • System designers refine to support • hardware partitioning • analogue/digital partitioning • concrete filter designs • specific acquisition strategies • apportion implementation loss budgets • Implementers refine to • exploit pre-existing object libraries • compensate for compiler limitations

14. Hierarchical decomposition • Entity • module of specified behaviour • not necessarily an implementation object • Message • user defined data types (and array shapes) • four scheduling flow types • Hierarchical Diagrams • message flow diagrams • statecharts • Leaf specification • mathematical definition

15. (UML) Statechart • WDL extension to UML: • state behaviour may be a message flow

16. Message Flow Diagram • WDL Message Flow Diagram • each arc has defined data and flow type, connecting at ports • each entity is self-scheduling - rendezvous of relevant ports • external ports to define hierarchy • cf. UML Collaboration diagram • external scheduling, connection points have no semantics

17. FM3TR • Future Multi-band Multi-waveform Modular Tactical Radio • FM3TR Technical Working Group (Fr-Ge-UK-US) • 30 - 400 MHz • 25 kHz channels • 25 kbits CPFSK • 250 - 2000 hops/second • 16 kbits transparent (voice) • 9.6 kbits coded (data)

18. FM3TR Protocol Layers

19. FM3TR Physical Layer

20. FM3TR Physical Layer State Machine

21. Hop Modulator

22. Hop Rise Time • constraint: shift.out = 0; • constraint: freq.out = hop.frequency; • constraint: amp.out = range { • minimum 0; value 0.5 * (1 - cos(2*pi*t/config.rise_time)); maximum 1; };

23. Language for specification • need expressions for • configuration constraints, state machine guards • need statements for • state machine actions • need types for • messages • need a language • implementation languages do not specify • specification languages are unapproachable • specification languages have unhelpful focus • new language is new

24. Specification • entity Subtractor { in minuend; in subtrahend; out difference; response minuend subtrahend // Whenever a rendezvous of { // minuend and subtrahend exists specification { // receive minuend and subtrahend difference(minuend - subtrahend); // subtract values }; // send to difference }; }; • Polymorphic • type, shape, flow, language

25. Hardware Mapping • Dedicated hardware • direct compilation • one ‘executable’ per ‘execution unit’ • General Purpose ‘Virtual’ hardware - software radio • CORBA components • software processes • HLA entities • identify components and messages • indirect compilation • one executable per component per platform • one interface declaration per message • configuration profiles per application

26. FM3TR LayersasJTRSComponentsandMessages

27. JTRS Mapping for FM3TR

28. WDL & JTRS Summary • WDL • efficient methodology for developing many waveforms • provides unambiguous specification • provides portable implementation • JTRS • a common radio architecture for waveform development • WDL with JTRS • specification and implementation via portable components • WDL without JTRS • specification and implementation via direct compilation

29. Summary • WDL specifies a determinate behaviour • Decomposition to manageable sub-specifications • Refinement to support a reference model • Refinement to support product implementations • Polymorphism to exploit generic libraries • Realistic scheduling models • Type-oriented code generation for flexibility

30. Status • Phase 1 • Initial consideration of language concepts • Example decomposition of FM3TR (1 month) • clearer • many anomalies reported back • Future • Better quality specifications • sponsor provides reference model • Semi-automated code generation • months rather than years