Why choose System on Module over SBC for embedded product development?
Single Board Computer (SBC) offers a ready-to-use embedded development platform for building end-products. SBC accelerates time-to-market and minimizes development cost and risk. However, System on Module (SoM)/Computer on Module (CoM) is a more appropriate choice for building embedded products. I will attempt to defend my assertion using a fictional case presented below.
In continuation to my previous blog post, Harry (CTO of BestECG company) on being asked by the company’s CEO on why he chose SoM instead of SBC for embedded development of ECGs, Harry presented two major benefits of using SoM over SBC that makes the former better aligned to meet the demands of embedded market.
One of the critical challenges that Harry faced as a CTO was to keep pace with the rapid technological upgrades. With Moore’s Law in action, microprocessors and memory move to smaller process nodes within 2 years, which is less than the expected product life of an ECG machine. Customers’ demands, which include advanced performance, low power consumption, and compact machines, necessitate frequent design updates to the embedded platform. These design updates add to the development cost. By using pin-compatible SoMs for embedded development, Harry knocked-off platform obsolescence from his list of concerns.
The pin-compatible modules from Toradex enable plug-and-play for scaling-up platforms based on future technologies and market requirements. New modules can be easily connected to existing carrier boards, and the application software may need some minor updates. With SBCs, Harry would not have achieved platform scalability as the board comes with fixed computing and memory sections. In order to accommodate latest tech advances, he would need to use the new SBCs available in the market.
SBCs come with fixed computing, memory, and I/O sections, all of which are integrated on a single printed circuit board (PCB). The I/Os, size & configuration are already fixed, so it not possible to customize the board as per the needs of the application. Harry’s options are limited to using the available SBCs, which come with standard I/Os, that may not have all the I/Os needed for the ECG machines. As per his design requirements, Harry can hook-up other peripherals to the SBC; however, such a solution is not flexible enough and will end up taking a lot of space, which would increase the platform’s size.
The embedded platform (CoM + Carrier Board)
The end-product: ECG Machine
By using SoMs, Harry segregated the computing and memory section from the I/O section. The carrier board, which connects to the SoM, houses all I/Os needed for ECG machines. Harry designs and develops the carrier board as per his size and configuration requirements, and then connects a SoM to it. The entire platform, which has the least possible size, is tuned to his design requirements. The combination of an off-the-shelf SoM and a compatible carrier board offers a platform that is both flexible and scalable.
By choosing SoMs over SBCs as a replacement for chip-based development, Harry was able to make the embedded platform future-proof and customizable. SBCs are ideal for applications that may not have specific requirements in terms of size, I/O, and configuration. A decision to choose either SoM or SBC depends on the specific project requirements and sales volume.
Now, you may be thinking that there so many vendors of SoMs in the embedded market, then why did Harry choose Toradex as the preferred SoM vendor? Check out my next blog that elucidates why Toradex would be your ideal SoM partner.
**This is a work of fiction. Names, characters, businesses, places, events and incidents are either the products of the author’s imagination or used in a fictitious manner. Any resemblance to actual persons, living or dead, or actual events is purely coincidental.