How is Industrial Embedded System Design Different For Small Companies?

Background:

As electronic sensing and processing power increases, more and more companies are coming out with great ideas that are functionally and financially feasible. The problem shifts more from “if we can implement these ideas” to “how we can implement these ideas.” Large companies have had the resources for years, and in some cases decades, to embed electronic intelligence into their products. The threshold for feasibility is decreasing, making it easier for smaller companies to enter the market. This is mainly due to:

• Lower cost per processing operation
• Lower cost per bit of information stored
• Lower cost per bit of information communicated
• Continued miniaturization of electronics
• Lower power consumption per processing operation

To be clear, when I say “small companies,” I mean those with fewer than 100 employees. I’m talking about companies in the industrial space (v.s. consumer), that manufacture sub-systems or systems that are generally more expensive (~$1,000s – $100,000s per unit), and have a relatively low production volume (10s to 100s of units per year).

The differences between embedded design for small and large companies matter because:

1. They can help small companies become aware of potential pitfalls before they get in too deep.
2. They can level the playing field for small companies.
   

Differences:

The main differences between embedded design for small companies versus large companies can be grouped into four main categories: capital, people, process, and organization.

Capital

Smaller companies generally have less working capital. They may have limited funds for:

• Development and debugging tools (e.g. Xilinx Vivado, Intel Quartus Prime, OrCAD, Eclipse) for doing schematic capture, board layout, simulations, and software/firmware development can range from free to sometimes costing thousands to tens of thousands of dollars to purchase, with an additional annual maintenance cost for each tool.
• Lab equipment, such as logic analyzers and oscilloscopes (e.g. Tektronix Logic Analyzers,  Tektronix Oscilloscopes), can cost thousands to several tens of thousands of dollars per piece of equipment. There are less expensive routes for initial cost, but keep in mind that generally speaking (in steady state), you get what you pay for, so a piece of equipment that has a lower purchase price may have lower performance (so make sure you understand your needs), lower reliability, or take more time to use. This last point is one that people often don’t weigh strongly enough in their decision-making. Time is often one of the engineering community’s most valuable resources. Another option is renting equipment. This comes with the obvious benefit of lower cost, but the risk is the possibility of out-of-calibration or misuse from the previous renter.
• Lab space – make sure to have enough room for development hardware, lab equipment, and computers (as well as enough power to handle all this gear). In addition, ESD is an important aspect of dealing with sensitive electronic components (check out ANSI/ESD standards). Components can be fried immediately, or sometimes worse, set up for a latent failure.

People

• Team sizes are often much smaller. Whereas a larger company may have several people that only do embedded software or only do embedded hardware, a smaller company might have an entire product development team that is just a handful of people, limiting the expertise to what is truly core for the company. An embedded developer in a small company might wear many hats, or there may not be an embedded developer at all and the company may rely on external resources to augment the team.
• Focus: smaller companies often rely on particular domain expertise. This is the core of why they (the companies) exist, and may be what keeps them afloat. They may be scientists with a really cool new idea, or they may be a more mechanically oriented company that builds electro-mechanical machines or equipment. Because of this, they may not have the ability or inclination to become experts with embedded systems. The algorithm may be very important to the smaller company, but the way that it is implemented may not be. Having some capability to sense a particular property or measure a particular parameter may be very relevant, but how it gets done may not be.

Organization

• Agility: Small companies are able to respond/react to market feedback faster. This Tech Crunch article discusses some ways in which bigger companies are trying to behave more like smaller companies: How Big Companies Are Becoming Entrepreneurial
• Small teams feel ripples from small events more than a larger company would. For example, if someone gets pulled off onto another project or leaves the company, a larger company may have the resources to plug in a new person, but a smaller company may not have this ability. Even losing a 25 percent of a full-time person on a small team that can’t be backfilled can be detrimental to a project.
• Small companies generally have less red tape to go through in order to get approvals faster and try things outside the scope of what is considered normal. For example, if a new embedded system has been released to a customer, and that customer needs a feature that isn’t available in the release, the smaller company will likely have a much easier time getting approval to add the new feature if it makes sense than if the same request is made to a larger company.

Process

• A large company may have a very well-defined, rigorous process for development, such as various design review gates, release processes, and documentation, whereas smaller companies may just focus on getting stuff done. The benefit is that the small company may get through development faster, however the risk is that if there is a flaw in the design, or bugs aren’t caught, it gets more and more expensive to fix later on (check this out: NASA – Error Cost Escalation Through the Project Life Cycle ; even though it’s old and based on developing systems that are very complex, the general trend likely holds, although the multipliers likely go down significantly).
• Smaller companies are less likely to develop a rigorous set of requirements and specifications, and the embedded developer will likely be involved throughout the project, whereas in a larger company they may not get involved until well into the project, where they are handed a set of derived requirements for their portion of the design.
• Larger companies may be more mature from a configuration management standpoint, including source code control, release process and version control.

So What Now?

Hopefully this article improved or solidified your mental model in some way and you feel more confident to take the next steps either on your own or engaging with an external company.  If you’d like to chat about your embedded needs, you can reach out to us here. If you’d like to learn more about how we can help with your industrial embedded needs, see here.  Or, if you’d like more information on industrial embedded systems, check out our resources page.