At some point, someone has to make it all work. Integration is where design meets reality, where theoretical meets practical implementation. In this discussion, we’ll cover some guidelines that may help ensure the success of your next systems integration project.
A wealth of published content is dedicated to descriptions of technology and components for industrial automation, and deservedly so, for these are the foundation of the capability of today’s cutting-edge production systems. Interesting production applications as well are often highlighted in publications, webinars, and conferences along with details on the unique and challenging tasks being performed. Somewhere in-between the components and the finished system lies the challenging and critical task of turning technology into a working application; this is systems integration.
Systems integration is a very broad term used in a wide variety of disciplines. In each case, a successful system implementation is the final goal, but the tasks and paths to achieve that goal are different for each type of project. This discussion focuses exclusively on the integration of automation cells, machines, and devices for production and quality applications in an industrial environment.
Over many years of designing and building small systems for industrial automation, each using a wide variety of core enabling technologies (in particular, machine vision, controls, motion, and robotics), I’ve formulated some thoughts about what constitutes a viable set of guidelines for successful systems integration in this environment. Recently, I compiled those into the following list with perhaps some obvious and some not so obvious. It is a fluid list, open to revision and editing with many possibilities for additions; so include your own thoughts and if you don’t have one already, build this into a formal process to help ensure your next integration projects go smoothly and produce successful results.
Develop and use a formal process for application analysis
Successful systems integration starts well before the hands-on work. Application analysis might be a part of the pre-sales/order process, or the first task in project execution. In any case, it is a critical step which must be undertaken in order to set the stage for a successful integration project.
Application analysis is the task of analyzing the needs of the proposed operation, process, or automation and gathering all of the application details. Informally, application analysis can be said to be an exercise in asking a lot of questions, and in knowing exactly which questions to ask.
Some of the key investigation areas that might be covered in a typical application analysis for an industrial project would include:
- Analyze the criteria for the targeted application. What needs does the automation or inspection system fulfill in the overall process? Are there alternatives to the stated procedures? How will the system benefit the process? Is there a way to do it differently from the current request that will produce better results or be more efficient?
- Develop a thorough description of the parts, components, and assemblies that are to be processed by the proposed system. What are the possible styles and how might they change in the future? What variations in size, shape, geometry, structure, color, etc. might be expected in the course of normal operation? Define special characteristics that might affect handling, processing, inspection and other system functions.
- Examine the broader production process. How is the part, component, assembly manufactured? What are the required processing rates and number of shifts? What is the impact if the proposed system mishandles, damages, incorrectly inspects the target part or assembly? What are the overall benefits of the proposed system to the process?
Understand what specific criteria will impact the success of the application and how those criteria square with stated or anticipated expectations.
Part of the application analysis could also be the consideration of business issues, in particular defining project responsibilities, schedules, and other performance expectations.
Specify for success
It is critical to start an integration project with a “project specification,” something that fully communicates the specific functions and performance of the system that will be designed and integrated. It is based on the information and understanding of the project that was gained during the application analysis. Some might call this a “preliminary design,” and whatever the terminology it will be used as a roadmap that drives the actual system final design process.
The project specification should address the technologies that will enable the proposed system, and the concepts for their use and integration. It should identify functions and operations that are to be executed by the system, as well as the related performance requirements.
A project specification should identify system limitations and exceptions (failure modes) that might occur in the system as designed. It would be unusual indeed if the system had absolutely no limitations or exceptions; that probably would indicate an incomplete application analysis was performed.
Importantly, a project specification should/must state the proposed acceptance criteria for the system. This quantifies the metrics that will indicate the system is performing as designed, and eliminates misunderstandings and unfulfilled expectations should any question arise once the system is in operation.
Identify the “critical path” components
Many of today’s automation systems incorporate cutting-edge technologies like machine vision, robotics, specialized controls, and other components that, for a given process, might be called a “critical path” component. This coined term is meant to describe a component that, if it fails to perform as needed in the system, might thwart the overall operation of the entire project.
This is not just a component that could fail and require maintenance or replacement sometime down the road. A good example would be a robotic pick and place operation that requires machine vision to guide the robot to pick up an object. In this case, the machine vision is the “critical path” component. If that technology is not correctly understood, specified and designed, the entire system will be unreliable or will fail to meet performance criteria.
Identify these critical components, then spend 80% of your specification and design time on them. Consideration of the capabilities and needs of the “critical path” components should drive the design. Where appropriate, incorporate system layouts, automation concepts, and perhaps auxiliary components that could enhance and/or ensure the best function of the key technology component as opposed to trying to make the technology fit an incompatible design. An example of this type of component from the machine vision world is the design of correct lighting and part presentation that guarantees reliable imaging. Similarly, if for example a flexible feeding system is critical to the application, one would take special care to be sure the technology was specified to accommodate all part variation and able to deliver the parts to the proposed automation at a rate and orientation suitable for the process.
In cases where a new system might need to operate with existing automation, limitations in the existing system might be present that impact the function, reliability or even speed of a “critical path” component in the proposed integration. It is critical to address this situation, either by changing the existing automation or components, or by appropriately limiting expectations for the final system performance based on the constraints of the old process.
Also, as part of this process, be sure to “try before you buy.” Examine and test the critical technology and specific components to ensure that they perform as required. Fully prototype the anticipated functions with production parts or assemblies.
Integrate with a purpose and plan
Even with diligent analysis, specification, and design, building a complex automation system is by no means a trivial task. Certainly the challenges of executing the mechanical design are very important. This guideline though refers to the successful integration of the disparate technologies that will come together in a smoothly functioning system.
Having a “purpose and plan” for component integration means the creation of documentation that fully describes the function of any specific component in the system and details how each component must interact with the others. This goes beyond system specification and focuses on the details of the configurations that will enable and promote efficient and timely applications engineering. Depending on the project, the documentation might include anything from timing diagrams to I/O lists to communication protocols.
With planning and purpose in mind, some keys to success would include:
- Optimize communications between connected components. Sometimes the last thing addressed in a complex system is the nature of and technique for communications between the various key components. Implement and test communications early in the integration process, and don’t cut corners; using an easy-to-configure protocol might save engineering time even though the initial cost of the option could be higher.
- Use all of the tools. A common mistake in machine vision integration, this directive translates well to a variety of technologies. Don’t be a “one trick pony,” and implement only the most basic tool, algorithm, or logic flow and hope it will be reliable for a varying production environment. Learn and use the full capability of the component to arrive at the most robust integration.
- Minimize or eliminate end-user parameter adjustment. That cutting edge GUI is great for ease of use, and doesn’t always have to be populated with a control for every variable used in the system. Changing functional parameters is excellent for system tuning at install, but consider having different modes in the HMI appropriate for different purposes.
- Test frequently and on a statistically significant sample set. This mandate is self-explanatory; test the system throughout the integration process as various parts of the system come online. Ensure that during testing, the device or component is exposed to enough real-world part variation to expose potential problems in the design or implementation. Make final testing a priority prior to shipment, and have in place a formal functional acceptance test plan.
Installation – Refine, not design, online
The time to test and make system changes without exception is prior to installation. Use the installation time with online production parts to refine and fine-tune the system integration as necessary. To design a system online means that an unfinished system hit the floor, and the result often is unreliability or even performance failure.
Have and use a validation plan
The system is not complete until it has been validated as ready for production. Functional criteria and the formal validation plan should have been documented at system design time. The validation process should occur over a significant operational period of time, and should encompass all of the part styles and variations that were identified in the application analysis and system specification. One should not expect to make changes to the system after validation, nor should there be changes to the system requirements and expectations at this point.
Manage the project
Finally, don’t overlook all of the higher-level organizational paths to success that are more related to formal project management than to the nuts and bolts of systems integration; develop a project team with a designated manager or champion, work with a schedule and review and update it frequently, manage expectations—both the customer’s and yours.
Tailor these guidelines to your integration projects, and enjoy success with every application.