1 / 15

SDL & Requirements of Signalling Systems

SDL & Requirements of Signalling Systems. William H. Skelton SOLINET, Stuttgart. Contents. Background Signalling Requirements Possible Evolution. SDL History. Origins as a graphical representation Mapping from presentation to execution Enhanced to ‚compete‘ with C++ & OO Consolidation

myra
Download Presentation

SDL & Requirements of Signalling Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SDL & Requirements of Signalling Systems William H. Skelton SOLINET, Stuttgart

  2. Contents • Background • Signalling Requirements • Possible Evolution

  3. SDL History • Origins as a graphical representation • Mapping from presentation to execution • Enhanced to ‚compete‘ with C++ & OO • Consolidation • Market forces • Technology management

  4. SDL Strong Points • Graphical Representation • Intuitive, easy to learn • System Organisation & Execution Flow • Concept of States & Signals • FSM specific • Simplifies validation & diagnosis

  5. SDL Weak Points • Complexity affects tools & users • Tools are complex • Users need skill profiles • SDL, TTCN & MSC evolved separately • Validation & Maintenance out of scope • C, C++, C#, Java have evolved faster • Commercial tools are more powerful

  6. Signalling Systems • Based on FSMs • Independent specialist domain • High reliability • Intense competition • Wide-range of applications • Communicating embedded systems • Relatively long life-cycle

  7. Typical SDL Functionality • Hierarchical Instantiation & Connectivity • Static, not dynamic • States, Signals, Timers, Variables • Types (Bit Oriented & ASN.1) • Encoding, decoding & formatting

  8. Work Processes • Implementation • Implement, Validate, Maintain • Specify, Design, Code, Execute • Validation • Specify, Design, Code, Execute • Maintenance • Diagnose, Analyse, Implement, Validate

  9. Information Content • Implementation • Intended behaviour • Validation • Expected behaviour • Actual behaviour under test • Maintenance • Actual behaviour in live use

  10. Information Reuse • Implementation • Component libraries (stacks, types) • Validation • Interfaces (Signals, Parameters) • Preambles, postambles, procedures • Subset of intended behaviour • Maintenance • Subset of intended behaviour

  11. Methodology Overlap • Implementation SDL (& MSC) • Validation TTCN (& MSC) • Maintenance MSC • SDL, TTCN, MSC Overlap • Information reuse is not implicit • Format conversion needed • De facto isolation of work processes

  12. Typical TTCN Functionality • As per SDL plus • Test Suites • Structure & Test Purposes • Constraints • Expected values for received parameters • Verdicts • Pass, Fail, Inconclusive

  13. Typical MSC Functionality • As per SDL (sub-set) plus • Signal transmission order • Parameters • Timing • Strong potential for automated checks • Link actual and intended behaviour

  14. Possible Evolution • Markets are driving evolution • Survival of most efficient technology • Efficient technology needs efficient tools • Efficient tools need efficient methodologies • Convergence of Methodologies • Implementation, validation & maintenance • MSC & TTCN overlap strongly with SDL • UML may be a wrapper for SDL

  15. Outlook • SDL ‘03 Conference • Stuttgart, 1st-4th July 2002 • Back to Basics • Telecoms & Automotive Applications • SDL Design Contest • Simplest, validated design • Traffic Light Controller • www.SDL-FORUM.org

More Related