1. Software rules in standardisation
Presentation Title
Software rules in standardisation
Dave Penkler
CTO HP OpenCall
Copyright © 2003 HP corporate presentation. All rights reserved.

2. Presentation Outline Introduction Interoperability Challenges
Presentation Title
Introduction
Interoperability Challenges
The software bulge
Software Interoperability
Conclusion
4/19/2019 HP
Copyright © 2003 HP corporate presentation. All rights reserved.

3. Introduction Interoperability, a working definition:
The ability of two or more users, devices, networks, information systems, components and applications to communicate, exchange information and use it.
Interoperability in a converged ICT environment:
User Experience of Content, Information and Communication services :
Satisfactory Quality, Performance and Cost
Safe, Secure & Dependable
Improving over time (Features, Cost, QoS etc)
While allowing technology innovation, vendor choice & competition:
Media formats, acquisition, protection, processing and rendering
Networking: Access, Transmission, Switching & Control
Information Services, Processing & Storage
Sensors & Transducers
And Maintaining Investment Protection in
Equipment
Software
Support functions
4/19/2019 HP

4. Interoperability Challenges
Explosion of Standards and Standard Development Organizations
170+ consortia listed at
High cost of specifying, testing and maintaining multilateral and multi-standard interoperability required for end-to-end interoperability
no clear owners
Consortia and their ecosystems at best address interoperability for specific technology / value chain related vertical or horizontal slices
the days of monolithic interoperable out of the box end-to-end standards are gone
Industry R&D investment in technology innovation:
Generating intellectual property
Looking for disruptive technology
Creating ecosystems / value chains around assets
Portability of services, content and user identity/addresses across
Multiple devices
Different Networks
Service Providers
4/19/2019 HP

5. The Software Bulge
Presentation Title
The bulk of ICT infrastructure development activities are now software related.
System on a Chip
Software defined radio
Digital Signal Processing
Middleware
Applications
New technology / functionality introduced through software upgrades to existing systems
Too expensive to replace whole system or build from scratch
Software component interoperability dependencies:
Vertical dependency on their deployment platform
Horizontal dependencies on multiple client/server/peer systems and services in the infrastructure
The well established standardization techniques must be extended address software interoperability
4/19/2019 HP
Copyright © 2003 HP corporate presentation. All rights reserved.

6. Standard Model for Interoperability
Peer to peer interoperability at each layer
Relays provide end to end interoperability with different standards in between
Tunnelling allows end to end interoperability by passing a lower layer protocol between two higher layer end points
Allows new technologies to be introduced “transparently”
Interoperability
Application
Application
Presentation
Presentation
Session
Session
Transport
Relay
Transport
Network
Relay N1 N2
Network
Link L1 L2 L2 L1
Link
Physical P1 P2 P2 P1
Physical
Data Format &
Protocol
Conformance
Testing Interfaces
4/19/2019 HP

7. Software Interoperability Environment
Implemented as Components hosted on specific containers.
Interoperability required with containers and application service components
Applications
Lacking open Conformance
Test specifications
Application
Services
Implemented as Components hosted on specific containers.
Abstraction layer for remote applications: e.g.: Authentication, file transfer, application protocols
MiddleWare
Common
System
Software
Existing Standards:
POSIX 1003
ISO DIS 23360
Operating
System
Implements “containers” that host and provide platform services to software Components
E.g: CORBA, J2EE, .NET
Hardware
Processing
Input/Output
Storage
Hardware / Software Platform
Software Interoperability
Portability of software components -> HW/OS Technology Choice/Innovation
Substitutability of components and containers: -> SW Choice/Innovation
Open standards with detailed conformance test specifications enable Portability, Substitutability and investment protection
4/19/2019 HP

8. The Software Component model
Open or proprietary component implementation
A Vehicle for introducing IPR and differentiation
Communications
Standardisation
Focus
Vertical
Interoperability
API
Standardised
Service interface
Portability
Service Provider Interface
Component
Horizontal
Interoperability
Substitutability
Standardised
Protocol interface
Portability
Service User Interfaces
Software
Standardisation
Focus
Vertical
Interoperability
API
Standardised
Interfaces
4/19/2019 HP

9. Software Interoperability Issues
Fragmentation due to multiple container technologies and incompatible implementations
Proprietary control of important container technology
Lack of well established software conformance test specification and execution methodologies
Standardised Interface Definition Languages not sufficient for conformance test specifications: need mapping conformance
Software test specification is still very labour intensive
Often neglected or deferred in standards development in order not to delay publication
Open source implementations of containers and components, although they can potentially help as reference implementations, are not a substitute for conformance test specifications.
Software layering is never perfect: changes in lower layers do impact and can obsolete upper layer implementations.
4/19/2019 HP

10. Current State & Future Work
Some progress in software standard specification & testing
UML 2.0 (OMG)
TTCN-3 (ETSI/ITU) – black box testing
Model Driven Architecture
Container SDK support for testing
Much work still needs to be done
Example of a successful approach
MHP Multimedia Home Platform (DVB Project)
Standard, test suites and implementations create a positive feedback loop
ETSI as custodian
4/19/2019 HP

11. Software interoperability Guidelines
Coverage:
Tests defined for all API’s of the standard as the standard itself is developed
Error cases and non-functional aspects must be taken into account
Core and optional API’s clearly defined
Openess:
Given Implementation technology or methodology must not be imposed by standard or conformance testing
Test suites made available to implementers in source form and also as executables where such exist
Early feedback from implementers to standard and test specification developers to fill gaps and resolve ambiguities
Profiles: Architectures based on horizontal and vertical profiles can help to reduce the combinatorial explosion of test cases and define useful conformance subsets of the APIs
Testing Independence: Separate conformance test specifications and tests for
Containers (aka Middleware)
Component provider API implementations
Component user API implementations
Container dependencies
Other component dependencies
Testing of a component should not necessitate retesting of container or components on which it depends
4/19/2019 HP

12. Conclusion Software Interoperability is important
Ensuring end to end horizontal and vertical software interoperability with open standards presents new challenges:
Complexity
Evolving
Will require continued constructive dialogue between
Standard development organisations
Technology suppliers
Equipment Manufacturers
Users
Regulators
Good conformance test specifications a prerequisite for software interoperability
Software conformance testing technology & methodologies not mature
Standards and conformance test specifications developed together
Independent execution of conformance certification tests
ETSI has a significant role to play
4/19/2019 HP

13. Presentation Title 4/19/2019 HP
Copyright © 2003 HP corporate presentation. All rights reserved.