.png)
When to use Raspberry Pi and when not to
In February 2012 the first Raspberry Pi was launched sparking a renaissance in the use of single board computers (SBC) for hobbyist activities, and for building low-cost embedded electronic device prototypes. A plethora of similar products soon appeared or gained popularity in the excitement surrounding the Raspberry Pi.
The excitement was well warranted as these platforms delivered unparalleled accessibility to powerful computing solutions, driven largely by the open-source community approach. The community surrounding each platform quickly developed solutions to common requirements and interfaces to virtually every type of off-the-shelf hardware component. As a result, Raspberry Pi and other types of SBCs quickly became the go-to development platform of choice for proof-of-concept design world-wide.
Indeed, Genesys does occasionally use SBCs for proof of concept designs, under very specific circumstances. For example, a client recently wanted a machine vision / edge AI solution within a few weeks to demonstrate a possible solution to government for a biosecurity emergency. By using a Raspberry Pi sitting on top of some existing Genesys modules we had an operational solution ready to show within a short amount of time.
In addition, some types of SBCs (and subsets of them such as System on Module) do have very legitimate place in commercially scalable designs. For example, Genesys frequently incorporates a Compulabs iMX8 system-on-chip processor in its designs where Linux is required, as well as the Jetson family of modules from NVIDIA where machine vision and edge AI is required.
So SBC’s do have a valid place in the product development journey toward commercialisation, particularly for low volume products with a short life or rapid evolution. However, the vast majority of "hobbyist" type SBCs such as the Raspberry Pi have not generally transitioned to mainstream use for products manufactured at scale. There are a number of reasons for this:
SBC modules are often not physically optimised for user centered enclosure designs. The off-the-shelf nature of these products means the device needs to be designed around the SBC, which does not optimise the usability or aesthetic value of the device.
The bill of materials for SBCs are not generally not optimised, with superfluous components and features that are not needed for the application. Custom commercial designs only use components that are needed and select those most aligned to the performance and functionality required.
There is no guarantee of a long supply life for any particular model of SBC. If the supplier discontinues the model, or there is a supply chain disruption (as is happening right now), the product developer has no option but to start again with another model. By contrast and by example, the Nordic range of microcontrollers are guaranteed to be available throughout the life of your product and designers can substitute individual components in a design if required.
The performance and energy budget of SBCs are generally not optimised for any individual application.
For some product types, these constraints are of little concern and many products based on SBCs do get commercialised. Where the business case does not stack up is when the product needs to be highly reliable and in compliance with industry standards in highly regulated industries. For example, the cyber-security of an SBC is generally not robust and not compliant with the new cyber-security standards required in most industries today.
In addition, the case for avoiding the use of SBCs for medical devices is compelling. In particular, the following areas of mandatory compliance essentially rule them out:
Off-the-shelf SBC modules are not developed or verified under ISO 13485 design controls and the hardware is not verified as being IEC 60601-1 compliant.
Generally speaking, it’s not possible to manufacture the SBCs yourself (under ISO 13485 controls) as the proprietary chipsets on SBCs are not available individually on a commercial basis. Similarly, as there is no traceability of components, there are no certificates or credentials on the rating for safety-critical components and no assurance of RoHS/REACH compliance.
Any open-source software that comes with the SBC or imported to your solution has not been developed or verified under design controls and is therefore not IEC 62304 compliant.
At a system level, there is no ISO 14971 risk analysis done on modules, which is another requirement, including no Failure Modes and Effects Analysis (FMEA) or single point of failure analysis
Despite these shortcomings, researchers working on medical devices and other high reliability products persist in using SBCs for developing proof-of-concept devices, usually because of the low cost. Unfortunately, that means years of effort in developing hardware and software must be discarded when moving to commercialise the product where regulatory compliance is required. While some learnings can be used to help define requirements and business logic/algorithm structures, generally speaking the development efforts need to start from scratch.
Some will argue that the incredibly low cost of SBCs and the plentiful libraries of open-source software justifies their use in proof-of-concept devices, and that will be true for many cash-strapped researchers or those that have very low certainty of ever proceeding to commercial scale production. However, the gap is now closing between SBCs and what commercially scalable development platforms can now offer.
Many electronics designers now offer low-cost proof-of-concept options with the hardware and core enabling software module using commercially scalable components. This makes the prototype device much easier to scale.
A very small number of design houses globally have also developed their prototyping platform under design controls. This provides a higher assurance of reliability and a faster pathway to regulatory compliance, without the need to ditch all development work when making the transition from the proof-of-concept stage.
For example, Genesys now offers a Wireless Wearable Sensing Platform which was developed under medical device design controls. The WWS platform has the most commonly required components on a base board, delivering all the “under the hood” enabling functions, such as battery management and Bluetooth connectivity, out of the box. Sensors unique to the application are placed on a plug-on sensor board. To get the platform operational for a proof-of-concept, only four things need to happen: We develop a custom sensor board, some application logic, an App page for displaying the data and, if necessary a 3D printed custom enclosure.
Contact us to discuss the most cost-effective way to develop your proof-of-concept and get it to market in the fastest timeframe, whilst setting yourself up for a rapid, cost-effective transition to MVP and beyond.
Комментарии