Software's growth shines spotlight on eliminating defects

  • 09-Oct-2015 06:10 EDT
ohtrcomveczero.jpg

Writing software for Deere combines now requires more than 60 programmers.


Software’s becoming a greater factor in vehicle development, prompting a heightened focus on reducing the number of defects in code. Early planning, discipline, and continuous attention to detail are a few of the techniques that can help design teams eliminate defects.

Unlike hardware and mechanical faults, software defects are often quite visible. Another difference is that programs are often judged by what they don’t do as well as by how well they work, according to panelists at the SAE 2015 Commercial Vehicle Engineering Congress.

“Any implementation that doesn’t meet customer needs has defects,” said Mike Repko of PACCAR Technical Center. Repko spoke during the “Getting to Zero Software Defects” executive panel.

The potential for defects is soaring along with the volume of software on advanced vehicles. Programs now provide many of the new features and functions on vehicles, marking a dramatic change from just a few years ago.

“Twenty years ago, two of us wrote all the software for a combine,” said Ashley Greer of Deere & Co. “Today we have 60 people, and that doesn’t include people in other facilities. We’re seeing a shift as software becomes the first thing developed. In the past, it was close to the last.”

That drive to push software issues earlier in the development process takes many forms. Model-based design is becoming far more common, as are simulations and validation.

“We need to focus on upfront validation so people aren’t writing code that isn’t what’s needed. We also need to simulate as much as possible early on in the process,” said Timothy Burns of Gulfstream Aerospace. He noted that while Gulfstream makes planes, its challenges are quite similar to those of commercial vehicle developers.

Verification is another critical step. Tests can be run throughout the development process, but that doesn’t always ensure a low defect count. Tests done in silos may not foretell faults that show up when all systems are integrated.

“Typically, testing approaches are vertically integrated, engines, hydraulics, etc.,” Burns said. “Ultimately, it all comes together in the flight deck, and the pilot looks at it as a horizontal system, not a bunch of vertical systems.”

There are a number of programming strategies created to maximize the efficiency of software development. Agile software development, which is particularly suited to the cross-functional demands of off-highway markets, is one part of a comprehensive programming strategy.

“Agile software development processes highlight a lot of problems, but it doesn’t fix them,” Greer said. “Managers have to make continuous improvement to make sure things get fixed and fewer problems arise in the future.”

These issues are almost certain to become more complex as the volume of software rises. Managers must be able to respond to the inevitable changes that occur during designs. Software changes in one area may impact other systems, but never enough time to check each system every time something’s altered.

“As software complexity grows, we need to better manage change,” Burns said. “From a scheduling perspective, you can’t examine every system every time you change one thing. It’s a big challenge to manage change.”

However, panelists agreed that it’s often difficult to scrupulously apply long-term strategies when day-to-day demands get in the way. Greer compared the goal of implementing best practices and building quality software to losing weight. People say they want to lose weight, but they don’t want to stop eating ice cream.

“We want quality software, but we don’t want to take the steps to get it,” he said. “Best practices for writing software are well known, why isn’t the industry following them?”

A strict programming environment is only part of the equation. Writing useful, reliable code requires an overall approach that includes technology and a realistic analysis of personnel.

“You need disciplined people who understand the technology and their role in development,” Repko said. “People think the processes are about things like standards, but the real key is to look at the people involved and the technologies that are involved, then customize everything around your goals, setting things up so the team can excel at building software that the customer wants.”

Panelists also spent a fair amount of time talking about those customer wants. Interactions with customers help companies determine what features and functions are needed. But costs always come into play.

“When you do focus groups, you also need to look at costs. People may want something, but they won’t pay for it,” Greer said. “Once products get into the field, we’re seeing faster feedback with social media.”


Author:
Mentions:
Share
HTML for Linking to Page
Page URL
Grade
Rate It
4.00 Avg. Rating

Related Items

Book
2013-12-05
Article
2016-08-26
Technical Paper / Journal Article
2010-10-05
Training / Education
2011-04-09
Technical Paper / Journal Article
2010-10-05
Article
2016-08-17
Article
2016-08-17
Training / Education
2013-04-09