Software rules in standardisation

1. Software rules in standardisation Dave Penkler CTO HP OpenCall

2. Presentation Outline • Introduction • Interoperability Challenges • The software bulge • Software Interoperability • Conclusion HP

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 HP

4. Interoperability Challenges • Explosion of Standards and Standard Development Organizations • 170+ consortia listed at http://www.consortiuminfo.org/links/interoperability/ • 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 HP

5. The Software Bulge • 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 HP

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 Transport Relay Relay Network N1 Network N2 Link L1 L2 L2 L1 Link P1 P2 P1 Physical P2 Physical Data Format & Protocol Conformance Testing Interfaces 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 HP

8. The Software Component model • Open or proprietary component implementation • A Vehicle for introducing IPR and differentiation Communications Standardisation Focus Vertical Interoperability Standardised Service interface API Portability Component Service Provider Interface Horizontal Interoperability Substitutability Standardised Protocol interface Portability Service User Interfaces Software Standardisation Focus Vertical Interoperability Standardised Interfaces API 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. 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 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 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 HP

13. HP