If you are thinking about hiring an external company to handle the development of your industrial embedded monitoring or control system, it is probably because your internal team is overwhelmed or your company lacks the necessary expertise.  

Evaluating and selecting the right vendor for embedded product system design can be a daunting task, fraught with numerous considerations and potential pitfalls.  

This article includes some of the key questions to ask when evaluating a vendor’s experience, track record, and adaptability so that you can make informed choices and forge successful partnerships. 

(Q) Have they done the exact project before?  
(A) That makes the decision easy. If they have done the exact project before, this is a good sign that they can do it again with a high degree of confidence. But…to be safe…ask the following questions: 

• How many industrial embedded projects they’ve done in the past year. 
• Can you share some case studies of similar complexity, criticality, and monitoring/control functionality? 
• What part of the case studies were the most difficult – or – what part of the project gave them the most difficulty? This helps you understand areas that warrant extra attention during the project. 

(Q) What language(s) will you use?  
(A) There are obviously dozens of languages and every language has fans and detractors.  You should care about this answer for a number of reasons: 

• Ask the vendor why they prefer one language over another. 
• What files will be provided at the end of the project? Your SOW should specify all software/firmware code as a minimum level deliverable. 
• Do we have the in-house capability to support future tweaks and fixes without the vendor’s dev team? 
• What about portability? If we need to switch tools, how portable is our code? 

(Q) What design files will be provided?  
(A) The schematic, layout, and Bill of Material files are incredibly useful as you consider new design versions. Keep control of all design artifacts, including schematics, artwork, fabrication and assembly files, etc. 

(Q) Will the vendor invest time into proper requirements definition?  
(A) Testable requirements make the world a better place. You communicate what the embedded controller needs to do via requirements. The only way to guarantee that your control will work in a particular way is to validate and test it against the requirements. Your requirements don’t need to capture everything – just enough to engage the vendor’s developers in a conversation so you can iterate build a requirements document that you both accept. 

(Q) Does your vendor bring unique IP to the project?  
(A) With any custom system, there are custom aspects that are developed from scratch and there are also reusable building blocks (hardware and software) that are part of your vendor’s IP. 

It is important to understand all rights associated with the use of that IP. Do you license it? Do you pay royalties on it? Can you modify it? Review the license agreement and understand how the terms may impact your budget. 

(Q) What about your own IP?  
(A) Let’s say you’d like to retain ownership in a unique algorithm developed during the project. Who owns it? How will it impact pricing if your vendor licenses it from you? As with all agreements, articulate the ownership and IP rights as part of your agreement. 

(Q) What is the depth and breadth of the vendor’s bench?  
(A) You’ll want capacity and support when you need it. Your vendor’s bench is a good indicator of responsiveness and risk reduction should something go wrong. 

(Q) What about support when products are in the field?  
(A) When units are in the field, there are likely going to be bug and warranty issues that arise. In the vendor agreement, define the level of support required before any work begins. Is T&M support okay once the product goes to market or will you need an entirely different level of support?