Implementing mechatronics: Software engineers are different

Embedded software development, a component of controls systems and mechatronics, differs from other engineering in key ways, according to respondents to recent Cambashi research interviews.

05/22/2013


V-model project development methodology was originally formulated by the Good Automated Manufacturing Practice (GAMP) Forum and has been incorporated into the Best Practices of the Control System Integrator Association. Left half of the V shows the planniSoftware has been an important component of control systems for many years. Control system software continues to grow in importance. For example, a faster processor in a control unit may allow a product to perform better and reduce costs by using simpler, lower cost mechanical parts, but only if the sensor and actuator control software are good enough. Software intensive, networked electronics are becoming increasingly central to the performance of products of all kinds, from industrial to consumer. More engineering teams are facing questions about the best way to handle software development as a key part of product development projects. [This includes mechatronics-based design, those integrating mechanical and electronics, including embedded software.]

Software development engineers, methods, and tools can be integrated into product development teams. Examples include industries and product types such as medical devices, radar subsystems, transportation equipment, production monitoring, aerospace, and communications. Approaches used by some of these companies can aid software development in new product introduction projects.

Software engineers are people

Company A’s head of engineering judged all development methods in use, software and hardware, in relation to a “good engineering” benchmark, which included proper framing of requirements, proper information and investigation of problems, and proper sign-off and communication of changes. The development team was modestly sized (tens, not hundreds). After some years of being distributed across multiple sites, this team (for hardware and software) had been centralized at one site. The most important engineering management tool was the Monday morning meeting of group leaders.

The company B development team was distributed across the world. Even so, during the one or two hours daily that spanned normal working hours for everyone on the team, team members would run a 45-minute online (headset, voice over IP, screen-sharing) exception reporting meeting. The development leader confirmed he had been tempted to use the company’s issue tracking system in place of this meeting, but was glad to be forcing direct contact among group leaders involved.

In both cases, direct communication among people was perceived as reducing the chance of misunderstanding and causing better articulation and prioritization of potentially complex follow-up actions. However, the products and teams involved were in many ways an outlier. These two teams handled mainly software; the electronic and mechanical parts of their products were relatively static, and not the key source of competitive advantage. The engineering was not very different from software-only development teams—the hardware could be treated as a special peripheral device. But these teams’ success using old-school, person-to-person communication as a core part of the development process is worth remembering.

Software is different

For products in which hardware is a larger part of the overall project, there were a range of approaches.

Company C highlighted issues relating to project management. The growth of software as a product development technology had been quite rapid and represented more than half of new product development costs and “nearly all the problems” at the time of the interview. Yet, going back 20 years, embedded software had been restricted to a few high-end products, provided by specialist subcontractors. Current project managers were mainly engineers who had been with the firm for many years. The hands-on experience of these people was largely electronics hardware development. The development organization used a product-team structure. This created a mismatch between project managers (mainly hardware development backgrounds), and 2-10 software engineers in the 5-20 lead product development teams. Though no crisis, project managers felt uncomfortable when they were unable to use their own experience to guide and question decisions, priorities, and especially time estimates provided by software people.

Company D had an organizational solution for these problems. It had similarly chosen product teams as the basic unit for development projects. Like company C, each product team contained a mix of specialists—mechanical, electrical, electronic, software. In recent years, company D gave the electronics and software people an additional “home” by grouping them into one “control-systems” unit, then assigning them back into product teams, but as a slightly autonomous control-system team. Overall management of objectives, tasks, and priorities derived from the product team. The control-system team leader in the product team (with a lot of autonomy over the hands-on tools and methods used by that particular control-system team) provided day-to-day management.

At the time of the research interview, organization D was aiming to make more use of the control-systems unit to develop more consistent use of tools, standards, and libraries and to find ways to achieve better levels of reuse (of everything, from know-how to architectures to platform electronics and software).

Central, not standard

Companies E, F, and G described centralized software organizations with names such as “software competence center” and “embedded software,” containing tens or hundreds of software engineers. Each product development project involved senior people from the software organization as part of a multidisciplinary project design team. Team output included outline architectures (with broad agreement on what would be in hardware and in software) and agreement on how to resource the project. Usually this meant a specification was taken back to the software team for implementation; sometimes it might be a temporary assignment for software engineers to work alongside the electronics team.

Projects inside these companies’ software organizations were not isolated; there was continuous communication with non-software people. But the buzz in the teams came from a pure software focus. For example, the teams were free to experiment and develop agile methods. The skill sets and technologies covered were diverse rather than standard, being driven mainly by the nature of the product and the underlying electronics, which would eventually run the software. However, the synchronization between software development and other technologies was “guaranteed” by strict stage-gate or similar processes. By whatever methods, the software team had to deliver exactly what was listed as the required software artifact for each stage-gate decision process.


<< First < Previous 1 2 Next > Last >>

No comments
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant Engineering 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.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.