Tips and Tricks: How to ruggedize an embedded control system
10 tips for making rugged control systems include knowing the end user of the product, how the product will be used, and operating conditions. Which are the most important attributes, and which one requires the most careful consideration?
Important tips for ruggedizing embedded control systems include knowing the end user of the product, how the product will be used, and operating conditions. Below the list, learn which attributes are most important and which one requires the most critical consideration.
- Who is the end user of the product?
- How will the product be used?
- What are (or will be) the conditions that the product will be exposed to?
- Where will the product be placed or located?
- What types of physical connections will be required?
- What materials should be considered in the design of the product?
- How will it be secured or attached?
- What level of testing and what specific tests will be required?
- When will the product be first installed?
- How and how often will it need to be accessed?
When ruggedizing an embedded system for use in automation, controls, or instrumentation, which of the attributes above are most important and why?
How the product will be used and the conditions to which the product will be exposed are the key elements when ruggedizing a design. The first part (usage) defines the parameters of expectation; the designer should insist on understanding how the end customer will be expected to use the product. Although the product itself may not require human interaction on a regular basis, it will require human manipulation during its lifetime. That manipulation will take many forms:
- Manufacturability: Someone has to be able to build it.
- Installation: Someone has to be able to install, mount, and connect to it. For large volumes this may have to be repeated many times in a day.
- Usage: One way or another and at some point someone will have to interface with the product.
- Serviceability: The device will need to be serviced; access to it while maintaining integrity of the design (at times in the field) will need careful consideration.
The second part (exposure) indicates the practical side of design. If the customer’s specification calls for a design that is water resistant, but the end user plans to attach the product to the bottom of a boat, then that, and not the specification, should be the primary consideration. In such cases it will be up to the designer to push back and have the specifications changed to meet the expected performance. Many good designs have failed in the field by adhering strictly to the customer’s requirements without challenge.
Tip number 8, involving “specific tests,” isn’t among the “most important” for various reasons, primarily because blindly requesting specific tests (or blanket tests) without knowing the aforementioned items is pointless. It will add unnecessary costs and potential bulk to the product. Invariably it will miss the mark with the end customer by being too expensive or too big.
Also, test specifications are at times used as a “cover all bases” method. It can be a wonderful thing to follow but also can be a dangerous road when taken as gospel without deep understanding of its intended application. Often customers will ask for a specific test standard to be followed “to the letter, and in its entirety.” Just because there is a test for the survivability of a product if it is thrown out of an airplane at 35,000 ft, doesn’t mean you have to design the product to adhere to it. The best design rule is to observe how a product will be used and push like mad to have the customer understand it.
- Emad Isaac, CTO for Morey Corp., provider of electronic manufacturing services.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.