System Architecture Design

Once the discovery process is complete and the requirements are firmed up, the next step is generally designing the system architecture. System architecture design is a process of mapping the requirements into the eventual hardware, firmware, software solutions. It is an iterative process that involves module partitioning, interface specification and data format standard definitions. System Architecture Design is perhaps our biggest strength – our ability to assess project requirements and distill them down into component blocks to realize real-world hardware, firmware and software implementations.

Module Partitioning

A system may be a single stand-alone device, but it is often composed of multiple modules, implemented on individual PCBs (Printed-Circuit Boards). For these more complex systems, we generally propose a number of architectures (depending on the complexities of the system) and then iterate against the requirements along with the client until a consensus is reached.

For example, we designed an antenna controller for a meteorological doppler radar that controlled 256 independent phase shifters from a single PC running the control software. The interface to the PC was defined and the data required to control each Phase Shifter was known, but the partitioning of a 1 to 256 multiplexer was non-obvious. Based on the initial requirements, we proposed 4 architectures. We ultimately settled on a slight variation on the one we recommended which divided the design into 2 major modules, the 256 individual phase shifters with a proprietary 2-wire synchronous serial interface and the other a 1 to 32 multiplexer that communicated with the PC and 32 phase shifters. Eight copies completes the system. The proprietary nature of the serial interface allows the clock to run just long enough to exchange data with the phase shifter so there is no additional clock noise present when the radar is actually receiving.

We can’t stress the importance of this step enough. Rarely, does the final partitioning match what was initially conceived. Time spent here, going back and forth with requirements, reliability, cost, maintenance, test, extensibility and so on, will pay dividends in the end. Even if this step is all that you need help with, give us a call – we will be happy to assist you.

Interface Specifications

Once the system is partitioned into modules, the next step is to determine the actual physical and electrical interface specifications. Here we determine if we should use standard bus architectures or proprietary interfaces, what types of connectors and cables to employ and what signalling to use. The choices here will impact the hardware, firmware and software designs as well as packaging, power and EMI (Electro-Magnetic Interference) to name a few. We have experience with high-speed parallel and serial bus architectures as well as slower, lower power interfaces for designs that are better served by them.

Data Format Standards

Often, standard bus architectures also define the format of the data that uses them. More often than not though (and certainly when using proprietary interfaces) the format of the data crossing the interface must be defined so that the hardware, firmware and software that must handle the data has a specification to work from. We work across these cross-disciplinary boundaries to ensure that the specifications are well documented and agreed upon to ensure the smooth integration of the final project.