Network Solutions / Communication Services Siemens Atea Siemens Atea, ICN NS/CS - Solution Development Jos Huybrighs, 3 march. 1999, Slide 1 SEESCOA –

Network Solutions / Communication ServicesSiemens Atea

Siemens Atea, ICN NS/CS - Solution Development Jos Huybrighs, 3 march. 1999, Slide 1

SEESCOA – Embedded SW in ICN NS/CS

SW Developmentin

Network Solutions &Communication Services

Jos Huybrighs (ICN NC SD)

[email protected]




ICN NS/CS: Development Domains

Enterprise systems: Inter-PBX Signaling Protocol Conversion PSTN/ISDN Signaling Protocol Conversion Telecommuting DECT

VPN PBX-to-PBX signaling tunneling through

PSTN/ISDN/Internet/Intranet Carrier systems:

VPN combined with VoIP: VPN-IP Residential Gateway




Facts and Figures

ICN NS/CS Number of SW designers: 30 > 5 years experience: 20 OO experience: 90% Architects / System Designers: 3 SW/HW Integration specialists: 4

Development split (effort) HW (including layout, mechanical eng.): 10% SW: 90%

Team organization HW: 1 person SW: 8..15 persons

Development Cost versus Total Cost Total Cost = Development Cost x




Enterprise Applications + VPN

Up0

Wireless DomainDECT

Up0

Leased Line

Inter-PBX Signaling

PSTN/ISDN

ProtocolConversion

VPN: PNE

signaling

CDGWirelessServer

DECT/LineInterface

PSTN/ISDN

PSTN/ISDN Domain

TelecommutingServer

TelecommutingClient

S0 Card

OTO

Up0

ECG

ProtocolConversion




Enterprise Applications:DECT Line Card (CMI)

HW: Motorola 683xx RTOS: COSMOS (own Siemens RTOS) SW: All own development, ‘C’ Main characteristics:

Protocol handling towards DECT basestations (ISDN-like) DECT handset signalling conversion to Optiset protocol (stimulus)

Tools: Greenhills Cost Constraints:

Memory size Issues:

Hard real-time constraints during initialization Multi-site development

Cost (Siemens Atea): 10 developers 30 PY




Enterprise Applications:VPN (PNE)

HW: AMD ELAN RTOS: Own asynchroneous method schedular SW: Mostly own development, except C++ Booch Components, C++ Main characteristics:

Inter-PBX protocol handling (30 channels) Bearer/Signaling separation and tunneling over a number of data transport

networks (x.25, IP, modem, in-band). Remote management using proprietary protocols.

Tools: OMT Modeling: StP Cadul

Cost constraints: Not really

Issues: 1st OO/C++ project Testability Hard real time constraints in some type of applications (e.g. in-band tone

detection) Cost: 30 PY




Enterprise Applications:Protocol Conversion (CDG)

HW: Intel 80188 RTOS: COSMOS SW: All own development, ‘C’ Main characteristics:

Signaling protocol conversion between different inter-PBX protocols Remote management using proprietary protocols.

Tools: Microsoft C, Linker/Locator (Intel) Intel ICE

Cost constraints: Not really

Issues: More or less hard real time constraints, depending on protocols

Cost: 20 PY




Enterprise Applications:Protocol Conversion - ECG

Based on the PNE platform Reuse of hardware and software

Main characteristics: Signaling protocol conversion between ‘old’ PSTN protocols and

ISDN. Cost constraints:

Not really Issues:

More or less hard real time constraints when capturing incoming line signals

Cost: 10 PY




VPN-IP

PBXPBX PBXPBX

PBXPBX

Q-SIG/DPNSS1

ClarentIP Gateway

ClarentIP Gateway

ClarentIP Gateway

PSR -PrivateSignaling Router




PSR

PSR

VoIP / H323

InternetInternetAccessAccess

ISDN / PSTN

ManagedIP-network

EDSS1

EDSS1

Q.SIG/DPNSSTunneling




VPN-IP: Characteristics

VPN-IP Based on PNE platform and functionality Main characteristics:

Idem as PNE, but transport of voice and data over IP VoIP through external Clarent gateway PNE hardware doesn’t have Ethernet interface - Special V.24

interface needed to the external VoIP gateway to pass signaling through an IP network.

Cost constraints: none Issues: relatively straightforward Cost: 5 PY




Residential Gateway

Residential Gateway

(MGCP) Local LAN

POTS phonesPOTS Fax Wireless

VoIP Gateway

Gatekeeper

Cable, xDSL, Ethernet

PSTN

...

Local PCs

Carrier IP Multimedia Network Call AgentFeature Server

Small PBX ?




Residential Gateway: Characteristics

HW: Infineon Tricore platform (RISC/DSP) RTOS: VxWorks or Infineon’s RTOS SW

Own (all C++): Telephony SW Other (buy): IP components (DHCP, SNMP, etc..)

Main characteristics: Decomposed gateway architecture with external Call Agent (master/slave) Remote management using open protocols (SNMP). Security issues: kerberos tickets, encryption (IPSec), SNMPv3

Tools: Rational Rose RealTime for UML modeling, Active Object services and

iterative development Visual C++ (simulation environment) Tasking toolset or Tornado (GNU) on the target No ICE

Cost constraints: Very hard: < $200

Issues: we are still learning, but IP routing has to be fast Cost (estimate): 20 PY




Why OO?

Drivers are: Speedup product development

Flexible, extensible and reusable architectures are fundamental Better way to deal with complexity

OO provides abstractions to keep complexity under control Better manageable development process

Better division of labor

Important issues: Disciplined analysis and design process is needed. Evolutionary and more iterative development will reduce risks

However, we are not there yet!




How do we do Project Management?

Effort estimation: It is still largely based on experience Metrics needed!

Staffing. How? Project leader who knows about OO Experts who have already done at least 2 OO projects Architect Team workers

Required skills: Prio1: Training in OO modeling (abstraction, ..).

Methodology: OMT (past projects), UML (new projects) Then: Training in OO language.

C++ because of real-time critical products.




How do we do Project Management?

Process Issues: Based on PPR/PPG The final goal however is: INCREMENTAL DEVELOPMENT

That’s how developers work! Progress Tracking:

We set the following milestones: Requirements OOA/D Component Test Integration Test

It turns out that tracking is easier due to better division of labor.




Our Product Cycle:1. Definition Phase System Definition and Requirements Capturing

This is key to develop quality software Documentation:

FDB1: business case FDB2: requirements specification FDB3: user interface issues FDB4: system specification

Definition phase ends with a “go/no-go” statement and the definition of 1 or more product packages/releases.

Current Definition Cycle doesn’t support appropriate OO modeling during system definition / analysis.Lack of resources/budget don’t allow upfront Use Case modeling and OO Analysis.




Our Product Cycle:2. Realization Phase: Step 1 Start with Specification

Design starts with the specification documents from the Definition Cycle (FDB1..FDB4).

FDB3/4 from Definition Cycle don’t provide enough detail to serve as an unambiguous functional specification.Therefore: we introduce an additional specification step:

Create a Functional Specification Output document: FDB5 Formal inspection.




Our Product Cycle:2. Realization Phase: Step 2 OO Analysis

Deals with: Architecture Analysis Modeling = “Ideal World Modeling”

Ignores platform, single or multi processor system, .. Important: come up with a software architecture which is robust,

extensible, and resistant to changes in functionality. Analysis = Teamwork

But, don’t involve too many! Analysis Documentation:

Through OMT/UML Case tool for creating the models Informal inspection




Our Product Cycle:2. Realization Phase: Step 3 OO Design

Deals with: Adding details to the logical and physical architecture Design of interfaces, data structures, state machines, .. Identification of new and existing reusable components, patterns,

frameworks Consider test strategy

Design = Teamwork Design Documentation:

Expanded and completed models, created by case tool Design document: FDB6 Test Concept Document: FDB8

Formal inspection




Our Product Cycle:2. Realization Phase: Step 4 Implementation

Principle: “Code a little, Test a little” Documentation: Source Files Inspections:

No systematic code reading Code reading is however important for ‘newcomers’.

There is no implementation description document. It doesn’t make too much sense.




Our Product Cycle:2. Realization Phase: Step 5 Component Test

Local, designer test using: Stubs, and/or TestManager test scenarios generator

Debugging and Testing Tools: TestManager, Debugger, Heap Checker




Our Product Cycle:2. Realization Phase: Step 6 Design Integration Test

Test Specification: FDB10 Formal inspection Test itself:

Simulation test, through TestManager scenarios Real, lab tests with the actual system




Our Product Cycle:2. Realization Phase: Step 7 System Test

Feature Integration Test Regression Test Load/Stress Test Tests are done by a separate team (no developers)

Field Trials




Our Experience with:OO Implementation Knowing C++ is not enough.

OO Modeling must be learned. Keep it simple

Restrict C++ to the basics Don’t use compiler specific features Set-up and use programming guideline and rules. Make them

part of the software development methodology Reuse common design patterns




Our Experience with:Patterns Try to make use of existing patterns

The ‘GOF’ Book The ‘Siemens’ Book

Create ‘own’ patterns. We currently have the following: Interface Classes: restrict visibility of classes Smart Pointers: reference counting on heap objects (derived

from documented C++ concepts) Asynchronous C++ method invocation Interworking ports and distributed objects (comparable with

concept of ‘proxy’ agents) Finite State Machines: objectification of states and events

They are hard to design They become stable after being used in +/- 3 projects




Our Experience with:Frameworks We have built a number of frameworks:

Generic OSI 7-layer framework Access communication layers through ‘Service Access Points’ and

standard OSI primitives Currently applied for:

X.25 EDSS1 (ISDN Layer3) LAP-D WinSocket (TCP/IP) Q.SIG

Operation and Maintenance Agent with ‘Manageable Objects’ They are very hard to design




Our Experience with: Reuse Component Reuse

We have a library of domain-specific components Areas: Foundation, system, containers, signalling and inter-object

messaging, fsm, devices, interrupt handling, .. Do-able

But, ‘Reuse Mindset’ is needed, It takes at least 3 tries to create a reusable component

Key to success: documentation and distributionPrinciple: intranet

Subsystem Reuse Hard to do because of application specific details Patterns and Frameworks must help in facilitating this kind of reuse.

Reuse, must be planned and taken into account at the project level.




Our Experience with: OO Testing Old, well-known practices still apply

Design for testability Add tracepoints throughout the application Perform component and integration test etc.

BUT

Finding, and solving errors in OO systems tend to be harder

There are no ‘globals’ which makes it difficult to locate the path to an error

Objects are continuously created and destroyed and so don’t leave any marks




Important Issues For Us

Documentation How and when Separate from design? Is Rose RealTime the solution?

Metrics Effort estimation still too much based on experience and ‘just

guessing’

Documents

Network Solutions / Communication Services Siemens Atea Siemens Atea, ICN NS/CS - Solution Development Jos Huybrighs, 3 march. 1999, Slide 1 SEESCOA –