(Source: Chesky/Shutterstock.com)
Modular hardware platforms are typically a collection of hardware such as backplanes, power supplies, cooling subsystems, and function boards that can be assembled in different ways and reused to meet different requirements. Modular hardware platforms can be proprietary or based upon an interoperable standards-compliant ecosystem. Using modular hardware platforms can greatly improve the development expense, time to market, quality, versatility, and risk of complex systems.
Consider a full-service supplier of computer network infrastructure. They might have families of servers, storage engines, routers, switches, optical and wireless communications devices, and various network appliances. If each of these product lines required the design and supply chain management for its own sets of backplanes, chassis, power supplies, cooling units, processor boards, storage boards, and I/O boards, that company could have hundreds of different designs to manage. If they were able to use the common modular platform approach, however, they might need to only develop a couple of chassis/backplane combinations, a few power and cooling options, a handful of board types, and common platform software to cover the same market. By using a standards-based modular platform, they might be able to buy interoperable solutions for many of these modular elements from an ecosystem of third-party suppliers, allowing them to focus only upon the specific parts of the development that differentiate their products, and let the larger supplier ecosystem worry about the commodity elements and never-ending updates. Let’s look at some of the tradeoffs and techniques used to modularize platforms.
What’s Your Platform of Choice? I will focus on the Advanced Telecom Computing Architecture, also known as AdvancedTCA or ATCA, standardized by PICMG (similar standards-based platforms include VME, VPX, CPCI, MicroTCA, and the Open Compute Project). AdvancedTCA is based upon a multi-slot chassis with a backplane that interconnects a number of circuit boards and rear transition modules. A typical chassis has 14 slots, although up to 16 are supported. Each slot accepts a large circuit board in the front, and a rear transition module in the back (often used for I/O expansion or to house storage). Large 48V power subsystems and high-flow fan trays permit power dissipations up to 400Wper slot, which is adequate for quad socket compute servers, large routers, and high-performance accelerator boards. A high-speed backplane interconnects and serves the boards. Two primary backplane topologies are available: dual star and mesh. In a dual star configuration, two slots contain fabric boards that act as central hubs in star networks. Two fabric boards enable fault tolerance, so a single point failure on one fabric board should still preserve traffic through the redundant board and allow the system to continue operating. The second option for backplanes is full mesh, where each board slot has dedicated paths to all other boards. The mesh option is especially valuable for routers, analytics, and supercomputer applications.
To configure a modular platform, the application’s requirements are partitioned into functions that fit on a number of boards. So, for example, an edge computing and analytics device could have a handful of processor boards, a few accelerator boards, two storage boards, I/O boards for both wireless and wireline/fiber interfaces, and fabric boards (one or two depending upon if high reliability is needed). These are supported by a chassis and backplane. A cooling subsystem, usually consisting of a fan tray and sensors, ensures the boards remain cool. A power system consisting of one or more power supplies and power distribution units convert the incoming energy from AC mains or a battery plant to the voltages needed by the boards. A system management infrastructure serves as the “autonomic nervous system” of the box, managing the power and cooling subsystems, monitoring the boards, managing booting and software updates, and reporting any alarms or abnormal conditions to higher-order network management. Taken together, this type of modular platform can be configured to meet a wide variety of requirements.
Platform software is also an important consideration. Many low-level functions are associated with the operating system, virtualization infrastructure, orchestration of functions, shared databases, common protocol stacks, and system management. If these functions are also treated as a common platform, this software can be written once and used as the software infrastructure for multiple platform applications. Then, the designer uses the application-specific software that runs on top of the common software platform to add the product or user-specific functions, and the entire system is tested and field deployed.
There are advantages when it comes to the application of common platforms. Common platforms are typically not 100 percent compliant to all system requirements. But platforms that are 95 percent compliant can often be found, and the small differences can be lived with, or customized if it means achieving the benefits of common platforms. The first time a platform is built that is intended to be used in multiple applications, it often takes a bit longer and costs a bit more than a single-use custom design would (because of the effort needed to plan for applicability to future applications). But, the second and subsequent use of the same platform assets will save lots of time and development budget, because platform assets can be reused, and not redeveloped.
There are also some trade-offs associated with platform supply chain strategy. Sometimes, it makes sense to build common platform elements in-house, especially if the anticipated volumes are high or if they embody some proprietary technologies. But, more often, it makes sense to look to a supplier ecosystem to provide some or all of the platform elements, and the development team takes on more an integration than primary design role. This approach lets you comparison shop among the products of multiple suppliers, and pick the best matches to your requirements for every element the ecosystem offers.
Standards-based common platforms can save you time and money, and improve the reliability and feature richness of your products.
CHARLES C. BYERS is Associate Chief Technology Officer of the Industrial Internet Consortium, now incorporating OpenFog. He works on the architecture and implementation of edge-fog computing systems, common platforms, media processing systems, and the Internet of Things. Previously, he was a Principal Engineer and Platform Architect with Cisco, and a Bell Labs Fellow at Alcatel-Lucent. During his three decades in the telecommunications networking industry, he has made significant contributions in areas including voice switching, broadband access, converged networks, VoIP, multimedia, video, modular platforms, edge-fog computing and IoT. He has also been a leader in several standards bodies, including serving as CTO for the Industrial Internet Consortium and OpenFog Consortium, and was a founding member of PICMG's AdvancedTCA, AdvancedMC, and MicroTCA subcommittees.
Mr. Byers received his B.S. in Electrical and Computer Engineering and an M.S. in Electrical Engineering from the University of Wisconsin, Madison. In his spare time, he likes travel, cooking, bicycling, and tinkering in his workshop. He holds over 80 US patents.