RoIP Systems Engineering Part II: Modularity - … · RoIP Systems Engineering Part II: Modularity...

Rev. A.02 25/09/2014

RoIP Systems Engineering Part II: Modularity The benefits of a purposeful modular system design

Testadvance pty/ltd

RoIP Systems Engineering Part II: Modularity

Copyright © testadvance pty/ltd 2010-14 Page 1 of 7

1

Disclaimer

The information herein is provided solely for the purpose of concept or product description and is not to be deemed as a statement of guaranteed properties.

This document is subject to change without notice. While this document and all the information contained herein and/or referred to have been carefully checked by testadvance, deviations cannot be completely ruled out. In the case errors are detected, the reader is kindly requested to notify testadvance.

In no event shall testadvance be responsible or liable for any loss or damage resulting from the use of e information provided herein manual or the application of the equipment.

© 2010 – 2014 by testadvance pty/ltd. All rights reserved

No part of this document may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of testadvance pty/ltd.



2

Table of Contents 1. Introduction ...................................................................................................................................... 3

2. Why modularity? .............................................................................................................................. 4

3. Summary .......................................................................................................................................... 7



3

1. Introduction

This paper is the second in a series on the practices we use to deliver a Radio-over-IP ‘solution’. It focuses on the principles and benefits of modular system design in RoIP based applications.

Radio-over-IP is a transport protocol that is independent of standards and proprietary or product constraints. Implementing a RoIP-based radio-system or network can substantially improve the cost-benefit of two-way radio. Both existing and future radio-assets can be integrated with modern IP-based infrastructure and non-radio systems. Integration via RoIP supports a wide range of radios of different formats and technologies. A suitably designed Radio-over-IP system allows an organisation to integrate, evolve and expand radio operations as and when they see fit. Customers can maximise cost-benefits and value from their two-way radio1 in ways that both fit and can evolve with their organisation.

Modularity is not a new concept. It has been applied in a wide range of fields, from furniture to space-exploration. The challenge lies in realising the best balance of functionality, configurability and cost in a clearly defined field of application – not just for one implementation, but over successive builds.

A RoIP system combines Radio-over-IP interfaces (RIU), Operator Consoles and System Applications. RIUs connect radios to an IP-network. The consoles provide voice communications, remote control of radios and enhanced radio management such as cross-patching and enhanced call options. Systems applications add functions such as logging and network administration. A RoIP-based radio-system furthers productivity beyond just the radio-operations themselves. Users across and even beyond the organisation benefit from deeper and broader access to the information provided by radio-communications.

Optimising ‘fit’ is critical to maximising cost-benefit and value for the customer. ‘Best-fit’ traditionally involved costly and lengthy custom design and implementation. Most radio networks and systems today are built from readily available HW & SW elements (Common-off-the-shelf, or COTS). Indeed, this makes sense given the better cost-benefits of a COTS solution over a custom design. Also, there is some inherent modularity in a COTS approach. We note two caveats: First, commercial products are designed with a wider range of other needs and different objectives in mind. And secondly, very few commercial products are designed and built to support seamless integration with other supplier’s products and platforms.

A modular system seeks to provide the ‘best of both worlds’. It provides excellent fit with minimum up-front engineering. A modular system is based on known and proven modules. This provides stakeholders from the outset a much higher level of confidence in the system’s ability to meet requirements – and at what cost. The ability to reconfigure and augment modules ensures short-term flexibility and mid- to long-term adaptability. This inherent resilience to uncertainty minimises the need to project future uncertainties – minimising costs, expediting deployment and delivering a much higher confidence in long term returns.

SoftRadio is such a modular system. It is based on a tried and proven modules. Modules are governed by a system-architecture that allows modules to interchanged, added and augmented without requiring changes to the system design as a whole. RoIP channels can be re-configured, e.g. allowing dynamic channel allocation or operator assignment. Different radio formats can be integrated and patched, providing interoperability e.g. between Airband (HF) and Trunked (e.g. TETRA) radio communications. Radio sub-systems can be configured for different IT-networks and geographies, e.g. to integrate remote locations Consoles can integrate different communications such as IP-phones with the radio-audio. Other modules such as Voice and Status logs can be used with other operational systems, such as supervisory systems.

The possibilities are extensive.

1 Note: Two-way radio, or radio is used collectively for LMR, PMR, DMR, SMR, Maritime, etc. systems and formats.



4

2. Why modularity?

We can define an artefact or system as being ‘modular’ where:

Functionality as a whole is deconstructed into discrete functions assigned to individual modules

The functional system as a whole can be recreated by re-assembling these modules

A simple example of a modular system is a wardrobe system. It may comprise a standardised frame, doors in different sizes and finish and various internal ‘modules’. A formalised system-architecture governs how modules are assembled into a system. Specific design-rules in turn govern how individual modules are implemented. Ideally, system-architecture and design rules include a level of flexibility in how modules are assembled into a system. This enables designers to develop variants of systems, each tailored to a given context, but using the same set of ‘building-blocks’. Modularization serves three core purposes:

Deconstructs complexity – systems are built up to the most complex level using ‘simple’ modules

Concurrent development – progress is the sum of completed areas, uncertainty is delineated

Resilience to change and uncertainty – modules can be reconfigured, added and removed

The key benefits to the customer are:

Minimise design and operating costs

Accelerate budgeting, design and deployment

Realise return on investment sooner and extend useable life-time of radio assets

Implementing modularity – sensibly

In the first phase of realising a modular system we deconstruct the required functionality into discrete functions, capabilities, etc. We apply three broad categories:

1. Core functionalities (e.g. voice transmission, radio control, networking) 2. Capacity and capability (number of RoIP channels, features / options supported), and 3. Applicability (breadth of implementations supported within the category)

Figure 1 Developing a Modular System for RoIP-based two-way Radio

Category 1 typically drives the design rules, category 2 design rules and architecture and category 3 ensures designers consider all feasible options that can arise from the targeted applications. The result is a set of commonly applicable requirements.



5

The second phase in designing a modular system is the logical extension of the first: Creating physical modules that can be reused over successive implementations. It stands to reason that if a single system can be designed using a modular approach, then one should be able to design modules that can be reused to build variants of systems for similar, but not identical implementations. Hence, we need to extend the system-architecture and design-rules to include requirements which can be reasonably expected.

How close the capabilities of such a more broadly scoped system can be matched to specific requirements of a unique build depends on its granularity. Obviously, the ‘smaller’ the modules, the higher the granularity and the better the possible fit. Yet at some stage granularity becomes cost-prohibitive: There is little benefit to be gained when the cost of configuring modules for a specific build approaches the cost of a custom design. Indeed, the value of a modular system is very much driven by how well trade-offs are addressed and managed. A ‘smart’ design isn’t stagnant. It continually revisits and incorporates external drivers (leading indicators) and learnings made in previous builds (lagging indicators).

Figure 2 Building Modular Systems for RoIP-based two-way radio

Distributed intelligence is a key design principle in modular systems. SoftRadio incorporates distributed intelligence purposefully across the modules of the system. Modules are designed with an amount of machine intelligence, i.e. autonomy that is commensurate with their function and position within the system architecture. There is little benefit to be gained from making lower-order modules ‘intelligent’. Conversely, there are substantial benefits to be gained from incorporating more intelligence in key modules such as the RoIP Interface Units and main console modules. A further benefit of distributed intelligence is that it enables the system to evolve with external drivers and learnings made. These can be e.g. technology developments or changing customer needs. In the majority of cases this ‘evolution’ can be achieved by updating the firmware in the individual module. In others, modules can be added. Only very seldom do modules require HW and SW upgrades. And in no case does the system architecture change.

The result is a purposefully designed Modular RoIP System that combines the fit of a purposely designed system with the ease, security and flexibility of off-the-shelf components.



6

The delivered cost-benefit and value add is substantial. For one, the vast majority of engineering has already been executed. The know-how resident in the system goes beyond the functional design – it incorporates both substantial learning and considerable foresight. Having this knowledge within the pre-defined modules and system architecture leverages the benefits across successive implementations. Customers minimise traditional ‘sunk costs’ in procurement and project-management. And last but not least, uncertainties are minimised and useful life-time and future costs and returns are quantifiable.

Figure 3 Positioning of modular systems

The value of a modular RoIP system such as SoftRadio is not determined solely by functional or operational benefits. Indeed, the ‘up front’ benefits of a modular system are often undervalued, if not overseen altogether. In the first paper in this series, we discussed the use of Systems Thinking to define a context specific framework. There a ‘top down’ approach is used to deconstruct a complex context and properly position and define a fitting solution. The modular system reflects this approach, just from the ‘bottom up’. Using the known capabilities and architecture, we can, together with the customer model different configurations with different costs and benefits – without having to actually design each different solution.

To use our simple wardrobe example: We select different ‘wardrobe modules’ from the ‘catalogue’ to try out different configurations and how each will fit the room where the wardrobe will be placed. As you can imagine, there are a substantial number of alternative configurations possible. Which one ultimately is chosen depends very much on the context (type of room, size, period or modern, etc.) and the benefits and value provided (storage space, convenience, looks, quality, etc.). It is interesting to note how this simple example demonstrates the impact influences and interactions beyond the functional requirements can have on a system’s design and the true benefits it provides.

Benefits of modular RoIP-system

Modularity is the logical continuance of Systems Thinking

Used with Agile Methods to design and develop a ‘best fit’ solution

Further highly efficient and effective matching of requirements and capabilities

Delineates areas of uncertainty and risk

Quickly identifies areas of fulfilment and areas of opportunity to extend benefits and add value

Provides for better identification and qualification of cost-benefit

Provides for better communication and project management



7

3. Summary

Modular systems come close to idealized design: The way to get the best outcome is to imagine what the ideal solution would be and then work backward to where one is today. This ensures one does not erect imaginary obstacles before even knowing what the ideal is.

Modular designs create options - Modular systems can evolve

A RoIP-based radio system needs to fulfil a set of requirements. These are (and need to be) based on credible expectation setting. This applies equally to the requirements the system needs to fulfil (functionality, benefits, life-time, etc.) and the requirements of building the system (time, human and technology resources, and of course, costs). Yet how requirements are determined very often places unnecessary limits on realising the full cost-benefit possible. Requirements are by necessity framed in the present time – defining future requirements can only be a projection of what is currently known. One can often observe that in such general requirements as the “ability to upgrade”. Instead, modular systems provide options designers can use to arrive at creative designs in areas where uncertainty is high, i.e. future needs. Stakeholders in turn can quantify ‘option costs’, rather than trying to project ‘uncertainty costs’.

Balancing evolutionary design and deterministic, pre-planned requirements

Modular systems are designed such that their respective parts (modules) interoperate under a wide range of circumstances. This inherent flexibility preserves the ability of the system to evolve as a whole. The construction of a modular system governed by design rules is not a deterministic undertaking that aims to pre-plan all future contingencies. The inherent flexibility to mix and match and augment modules creates options. These options, or permutations, allow unforeseeable developments to be supported. This process of building and maintaining a modular system is rather similar to the common understanding of evolution in that it is incremental, concurrent and not specifically pre-determined. This ability to adapt to changing requirements and influences and incorporate learnings is what enables customers to maximise returns over the lifetime of the system. And indeed, it is in no small part the result of the foresight applied.

Figure 4 Overview of SoftRadio modules and system architecture

RoIP Systems Engineering Part II: Modularity - … · RoIP Systems Engineering Part II: Modularity...

Documents

Transcript of RoIP Systems Engineering Part II: Modularity - … · RoIP Systems Engineering Part II: Modularity...