You’re in luck.  This calculator can start to give you a feel for the costs.  Note that I said “feel”.  That’s because it’s just a rough ballpark estimate.  There’s usually additional information that will change the costs that’s not easily captured in a calculator because there’s too many unique scenarios.  Reach out to us for more accurate pricing.

This calculator is intended to capture the engineering costs (mostly software development, debug, and integration) to develop the first unit.  Here are the major assumptions:

• COTS (off-the-shelf) hardware can be utilized.
• Hardware costs are not included.
• Decent requirements have been created.

Engineering Prototype Cost Calculator – for Industrial Embedded sub-systems that use COTS hardware

If you’re interested in considering Viewpoint for your development, check out our capabilities here, then reach out here.  If you’re looking for additional industrial embedded resources, check this out.

Outsourcing Industrial Embedded System Development Guide

10 Considerations before you have an embedded design company develop your industrial embedded monitoring or control system for you.

Consideration – How do I get a warm fuzzy that the EDC can solve my specific problem?

This is the most straightforward for you when the EDC has done your exact application in your industry.  However, given that the EDC is in the world of custom development, generally your design will be at least somewhat unique (if it’s not, it’s worth thinking about how you’re addressing a problem differently than someone that’s already in the market).

Why you should care

To get that warm fuzzy feeling that you’re after with the belief that the EDC will not only perform as needed, but that they’ve got your back and will actually challenge you on some of your thoughts on how to proceed.

Recommendation

1. Project stats – find out roughly how many industrial embedded projects they’ve done.
2. Case studies – look for them. Think beyond your specific application or industry, and ask yourself what similarities you see from level of complexity, mission criticality, and monitoring & control functionality standpoint.  For example, it’s a pretty different thing to locally control a single manufacturing machine at fast loop rates than it is to remotely monitor multiple deployments of some industrial equipment.
3. Capabilities bullets – look for them. It’s a pretty different level of capability to design a digital level shifting interface circuit than it is to be able to design a low noise 24-bit A/D multi-channel analog input circuit.
4. Ask them what aspects of the project they feel least comfortable with. This will give you a feel for what they’re most concerned about, even if they feel comfortable with your project overall.  This gives you thoughts on areas that you should pay close attention to during project execution.

Consideration – What language(s) will the EDC be coding in?

There are dozens of languages out there to write software applications. Many of them are not appropriate for embedded systems. Several are. Some of the more popular languages will include C/C++ for sequential processors and VHDL/Verilog for FPGAs.

Why you should care

Supportability – If you need to be able to make tweaks on your own post-delivery then you’ll need the IDE software to do so.

Portability – If you need to switch EDCs or switch tool chains you’ll need to find an EDC that supports the selected language(s).

Recommendation

1. Do a sanity check search on the web to get a feel for how common the languages are that your EDC is proposing. Don’t be afraid to ask the EDC why they prefer the language that they do. This can give you some good insight.
2. Make sure you understand what files will be provided to you, and set them as deliverables.  At a minimum, you’ll want to request all software/firmware source code files (e.g., .c, .vhd, etc.).  It can also be helpful to understand what versions of which IDEs are being used.

Consideration – What circuit board design files will you be provided by the EDC?

Chances are you won’t be able to modify the hardware design yourself, and it’s unlikely that you’ll convince a new EDC to take the design files, import them, and modify that design (there are just too many variables (e.g. libraries) in the setup of the design to trust that everything will just work).  However, it’s very helpful to have the schematic, layout, and BOM (Bill Of Materials) files to serve as breadcrumbs in reverse engineering much of the design intent in order to create a new version of that design.  Chances are that, even with the right files, they won’t be able to import the design and start from there.  They’ll have to start the schematic/artwork from scratch.

Why you should care

Supportability – if you need to create a new version of the design and you want to use a different EDC, having the right files will provide some breadcrumbs for them to assist in understanding design intent.

Recommendation

Make sure you understand what files will be provided to you, and set them as deliverables.  You’ll want to ask for:

• Schematic capture files
• Artwork files
• Fabrication & assembly files (Gerbers)
• BOM (Bill Of Materials)

Consideration – What hardware platform does the EDC use as their core building block?

There are lots of options out there for hardware platforms.  Depending on your application, you may be considering the likes of PC-104 stacks or similar, RasPi, Arduino, NI RIO, Avnet PicoZed, a fully custom board, or maybe even a PLC.  Be careful here, performance, ruggedness and reliability will vary greatly.  Choose cautiously.

Why you should care

You’re naturally going to care about the performance and environmental specifications of the hardware, so we won’t even get into that.

Lifecycle maintenance & obsolescence – while not the most fun aspect of the design cycle to deal with, this is an inevitable part.  The last thing you want is to be in a successful mature production phase only to find out that critical components are going obsolete and you have no path forward.

Future upgrades – if you’ll need to upgrade your design in the future, maybe with an expanded, limited, or just different, feature set.

Recommendation

1. Find out why the EDC thinks the selected hardware stack is a good choice for your scenario.
2. For lifecycle maintenance, find out about the manufacturers product lifecycle plans. Ask the EDC about how they handle and support life cycle management. In other words, who watches out for parts going obsolete? Who recommends last time buys?
3. If you care about future expansion possibilities, ask about: Processor headroom, Spare I/O, Controller variants.
4. Check out this white paper for details on finding a good spot for you on the COTS-custom spectrum.  There are off-the-shelf options out there.  You generally only want to do as much custom design as needed, given your performance requirements, projected volumes, and time-to-market constraints.

Consideration – What IP is the EDC bringing to the table?

Since you’re developing a custom system, there will likely be many custom aspects to the controller that need to be developed from scratch.  However, often times, companies develop their own IP (both hardware and software) for use across multiple projects as building blocks.

Why you should care

There may be limitations associated with the utilization of the EDC’s IP.  Maybe you pay royalties on units sold.  Maybe you retain rights to use the code as-is, but not to modify.

Generally speaking, the more IP the EDC has, the less NRE you’ll spend. Granted, the EDC is going to want to recoup some of their development costs, but chances are, pre-developed IP will save you in development costs.

Recommendation

Ask for the EDCs IP licensing agreement and learn what the terms are.

Consideration – What IP will be developed as part of this project?

How much do you care about protecting your IP?  Maybe you’ve developed a pretty cool algorithm that you’d like to retain ownership of.  Maybe you’re not doing anything horribly unique at the controller level, and maybe the EDC would like ownership of that IP for other future projects.

Why you should care

This can limit your use, or use by the EDC.

It also can affect pricing for the project and subsequent sales.  If the EDC finds the IP valuable for them, they may be willing to drop the price on the development work.

Recommendation

1. Articulate IP rights and ownership as part of the contract.
2. Consider a patent for a truly novel idea.

Consideration – How deep is the EDC’s bench?

You’re buying a capability.  The end product doesn’t exist yet.  Your needs relating to flexibility, responsiveness, risk reduction, and price sensitivity will drive what you care about here.

Why you should care

You want your project to be completed, and you want support when you have questions.

Recommendation

You generally are going to trade risk for price here.  You have to decide what balance you’re comfortable with.

Consideration – How will the EDC support me once units are fielded?

Depending on our scenario this could mean different things:

1. Like it or not, you’re likely going to be dealing with bugs and/or warranty returns in the field at some point.
2. You may have situations where different customers want different features.

Why you should care

When you’ve got fielded units, you don’t want to end up stranded, because you’ll end up with unhappy customers quickly.

Recommendation

1. Define the level of support desired up front before development begins. Do you want a certain level of support at a fixed price?  Are you happy with T&M support on an as-needed basis?
2. If different features are likely desired by different customers, and those features are understood ahead of time, the embedded controller can be architected differently, so have this discussion before development begins.

Consideration – How important does my project seem to the EDC during the sales process?

Do you feel the love, or are you feeling more like a bother?  If you’re feeling like you’re bothering the EDC before they win your business, how do you think things are going to go after they get your business?  Of course, not everyone can be top priority, otherwise there would be no top priority, but you don’t want to be at the bottom of the barrel either.  Somewhere in the middle may be just fine depending on your scenario.

Why you should care

This can be a good indicator of how they will treat you during project execution.

Recommendation

Sniff out where you fit in the priority of all their other projects.  Unfortunately, there’s no easy mechanism here.  You can ask them, but you may not get the most honest answer.  Some subtle indicators to look for to help see where you fit:

1. Tone of voice during conversations.
2. How often are you being asked to re-schedule because something else came up after you locked in a meeting time? This can happen unavoidably, but generally shouldn’t happen more than once during the sales phase of the project.
3. How long does it take for them to respond to your emails? Generally, initial emails should be answered within ~24 hours.  Further down, when the depth of technical detail is significant, it may require a handful of days for a detailed response.
4. Try to get references from prior clients, just be aware that the EDC might not be able to give them due to NDAs.

Consideration – Am I willing to invest time and energy into requirements development?

Requirements are the mechanism for communicating what the embedded controller needs to do. This step is often seen as not being value add, because you already know what you need (at least at a high level) in your head. You’ll want to use the requirements to create an acceptance test plan.

Why you should care

At the end of the day, you want your controller to work in a particular way. The way to validate and verify it is by testing it. In order to test, you need testable requirements.

Recommendation

Check out this industrial embedded requirements and spec template. You don’t need to necessarily capture everything on the first iteration. Take two hours to capture what you know as well as TBDs, then engage the embedded design house in a conversation and iterate from there.

As companies hone in on the core value they bring to the market, outsourcing various components and subsystems becomes a popular option. If you’re considering outsourcing the development of your industrial embedded monitoring or control system, it’s likely that either your internal resources are overloaded or perhaps your company doesn’t have the capability in-house.

If you’re considering us, you can learn some of the basics about us here.  If you’d like to see what we’d propose to solve your industrial embedded problem, reach out here to chat:

Introduction

In the embedded system world, beginning a new design project can be exciting. It’s easy to get swept away with the possibility of creating an innovative product that the market has not seen before, and that will exceed the customer’s expectations.

But prior to starting work, it’s essential for project leaders to consider all available skill sets within the design team. It’s equally important to have a clear understanding of what specific vendors can offer, in terms of the tools the vendor will be using, and the level of service they can be expected to deliver.

Additionally, project leaders need to consider—of course—the customer’s requirements around product specifications and the project deadline. For this reason, it’s essential to capture customer requirements in their entirety prior to starting the project, and to be sure the entire design engineering team is aware of those requirements. Lastly, solid and open inter-team communications, and the ability to coordinate widely varying personalities on the project, are also critical.

Simply put, ensuring a design project’s ultimate success requires an understanding of how to bring all of these things together.

Overlooking the intersection of all of these elements leads to errors, cost overruns, missed deadlines and a poorly designed product. A delivered product does not equal a successful product. And a completed project is not successful if your team was rushed, stressed and frustrated.

This white paper discusses the top five embedded system design fails and how you can avoid them.

Fail #1: choosing the wrong tools

 It’s not unusual for some team members to have stronger skill sets in some areas than in others. After all, different embedded systems require that your team employ different skills, based on whether the project calls for CAD or FPGA design software, for example, or whether the software language environment will be Microsoft (.Net), Oracle (Java), National Instruments (LabVIEW), or free and open source (Python, Ruby, GCC, etc.).

A common design fail is to choose one set of tools over another without considering what is both best for the success of the project and how many of your design engineers are knowledgeable about that particular tool. You should not choose tools based on who speaks first or most loudly in a project meeting, but it’s not unusual for tools to be chosen this way.

Do not fall into the temptation of a vendor’s persuasive sales pitch. Many will claim that they are faster, offer the best pricing, etc. If your team is inexperienced in using that vendor’s tools, the project timeline and budget can grow exponentially. On-the-job training can be costly and time-consuming, since your team members may spend more time learning new software or language than they do actually working on the design itself.

Conversely, sometimes it does make sense to train team members on a particular tool, as they can use this new knowledge in other projects. Most engineers like to learn new skills—and should. If training is a value-add for the team, plan to budget that as a separate line item, and on a separate schedule, from the project itself.

The best approach is to consider all readily available skill sets and tools, and to make decisions based on what will most efficiently and cost-effectively contribute to the project’s success.

Fail #2: choosing the wrong vendor

No two vendors are alike, but another common design fail is choosing one before considering the software they will be using, the inevitable bugs that software will introduce, and how capable your team is of fixing those bugs. Again, will the required fixes add time to the project that the schedule does not allow?

Another key vendor consideration is the service experience. Will the vendor be likely to work well with your team, be responsive and meet all necessary milestones? Will the work quality meet the required standards? If you have a smaller company, will the vendor be sympathetic to the limitations of your team’s size, skills and time constraints?

To avoid overlooking these key considerations, it’s best to understand the specifics of what the vendor is providing, the pain points or idiosyncrasies of that vendor (because there are always some to overcome), and to choose the vendor that best meets your requirements for both the product and the service experience.

Fail #3: incorrect resource allocation

Another design fail is overlooking the ability to outsource all or part of a project. Many organizations take the approach of always keeping all projects in-house. The goal, of course, is to maximize profit by controlling overhead costs. But forcing a small, already overworked design team to take on another large project will overburden resources. This not only leads to burnout within your team, it often sacrifices product quality due to unavoidable mistakes.

Conversely, in larger organizations, where design engineering costs can run into $100’s per hour, outsourcing all or part of a project can help alleviate budget overruns. For example, as mentioned previously, will the new project require additional training? It can make more sense to enlist a ready expert to take the helm.

The most strategic approach is to establish processes for considering available time and skill sets, and to assign projects in-house accordingly, or outsource when your resources or budget require it.

Fail #4: misunderstanding project requirements

Failing to conduct thorough customer interviews at the requirements-gathering phase is another common mistake. For example, it’s not only important to understand requirements around product color or weight, but also to understand specifics and reasons behind those requirements. “The communications bus shall be MIL-STD-1553” is an example of a good requirement.

On the other hand, sometimes the requirements are much less clear. “The embedded system will have high up-time.” How high? “The system will not weigh too much.” How much is too much? Is there wiggle room in either requirement? Understanding the reasons behind the product specifications can help avoid disastrous outcomes.

The smart approach to requirements-gathering is to involve all team members at the outset of your requirements-gathering phase. This should include the design engineering team, the management team, and the customer. First-hand knowledge is crucial, because vagary in the requirements-gathering phase leads to errors.

Fail #5: lack of communication

This is perhaps the most common design fail and the most difficult to avoid. It’s a universal truth that a talent for design does not equal good communication skills. Engineers of every type—including design engineers—are not immune to challenges around communication. But a lack of communication in a project can lead to a design failure in the end product. Overcoming this challenge requires a three-pronged approach.

1. First, it’s critical to make sure that for each project there is a strong manager or project lead in place to assist where needed. This person should be adept at proactively facilitating communication and working with individual team members to improve on areas of weakness. Is a team member unable to communicate effectively via email? Is another team member particularly reserved in a public forum, and unable to speak effectively (or at all) in meetings? Coaching can help. Of course, this always requires a willingness from the team member to hone those communications skills. It can’t be overemphasized that individual team members must take responsibility for communicating effectively as well.

2. The second essential is to have the manager or project lead assist in choosing the right communication format for each person on the project, whether that’s email, in-person meetings, conference calls, etc. (Just because someone is being coached doesn’t mean he or she will ever really excel in all communication areas).

3. Lastly, the importance of open and honest communications between management and engineering resources cannot be understated. This necessitates management’s willingness to consider whether the team is prepared to meet all the customer’s requirements for both specifications and timelines. The engineering team must feel comfortable providing feedback on what they think they can and cannot do within the specified time period—and to suggest outsourcing when necessary—without fear of losing their job.

Choose your failures carefully

Not all design fails spell disaster for a project. After all, some mistakes are necessary to gain knowledge for future projects. Yet other fails, like those mentioned above, lead to mistakes, cost overruns, damaged morale, unnecessary re-work and a dissatisfied customer. To ensure a project’s success, it’s critical to know the difference between the former and the latter.

Next Steps

If you’d like someone to take the industrial embedded development off your plate, you can learn more about how we can help or reach out to start a conversation.

If you’re deep into learning mode, check out these resources:

• Outsourcing Industrial Embedded System Development Guide
• Embedded Design for Large vs. Small Companies
• Industrial Embedded System Design Services – How much does it cost to prototype?
• The Embedded Design Checklist For New Designs