Software rules in standardisation Dave Penkler CTO HP

Software rules in standardisation Dave Penkler CTO HP Open. Call © 2004 Hewlett-Packard Development Company, L. P. The information contained herein is subject to change without notice

Presentation Outline • Introduction • Interoperability Challenges • The software bulge • Software Interoperability • Conclusion 12/14/2021 HP 2

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, Qo. S 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 12/14/2021 HP 3

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 multistandard 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 12/14/2021 HP 4

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 • 12/14/2021 The well established standardization techniques must be extended address software interoperability HP 5

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” Application Presentation Session Transport Network Link Physical Interoperability Relay L 1 P 1 N 1 L 2 P 2 N 2 L 1 P 1 Application Presentation Session Transport Network Link Physical Data Format & Protocol Conformance Testing Interfaces 12/14/2021 HP 6

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 Middle. Ware Existing Standards: POSIX 1003 ISO DIS 23360 Common System Software Operating System Hardware Processing Input/Output Storage Hardware / Software Platform • Implemented as Components hosted on specific containers. • Abstraction layer for remote applications: e. g. : Authentication, file transfer, application protocols Implements “containers” that host and provide platform services to software Components E. g: CORBA, J 2 EE, . NET • 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 12/14/2021 HP 7

The Software Component model • Open or proprietary component implementation • A Vehicle for introducing IPR and Vertical Standardised differentiation API Interoperability Communications Standardisation Focus Service interface Portability Service Provider Interface Substitutability Component Portability Service User Interfaces Vertical API Interoperability 12/14/2021 Standardised Interfaces HP Standardised Protocol interface Horizontal Interoperability Software Standardisat ion 8

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. 12/14/2021 HP 9

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 12/14/2021 HP 10

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 12/14/2021 HP 11

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 12/14/2021 HP 12

12/14/2021 HP 13