Posts

CASE

ABB Robotics

Business Transformation with Product Architecture

Executive Summary

ABB is a market leader in industrial robots and robot software, equipment and complete application solutions.


At the start of 2013, rising labour costs in key industrial markets, ever-increasing demands on quality, and cost reductions in robot design had led to an inflection point. Robots had become a very attractive alternative for many different industries.

Despite new and more aggressive competition, ABB Robotics was getting ready for a spike in the demand curve. And while it was increasingly important to protect prices, maintain market share, stay cost competitive and deliver orders faster and faster, the key question facing the executive management team was how to take advantage of the growth opportunities out there?

The answer was a modularization program and the results were significant:

  • 300% increase in the number of different controller cabinet products
  • 50% reduction in controller parts
  • 50% reduction in the size of smallest controller
  • All controllers ready for remote serviceability
  • 80 independent software development tracks – up from 1
  • < 1 month in time to market for new features – compared to 6 months before the program
  • 50% increase in robot arm assortment
  • Quadrupled production capacity.

 

The new product architecture had additional benefits in terms of process improvements and strategic product management, not least for the software team, where customer values and strategy could be embedded in the modules directly – for the very first time.

As software architecture can easily be circumvented by the coders, it is important to repeatedly go back and look at the reasons why certain functions were grouped into modules. We have done software modularity before, but this time we factored in customer values and strategy. I believe this makes our new architecture much stronger.

Roger Kulläng
Global Software Solution Architect
ABB Robotics

CONTACT

Working together with ABB Robotics on this modularization and transformation program have been challenging and as you can read, highly rewarding. The team at ABB are highly skilled when it comes to modularization and making business work. This project taught me a lot, and once again confirmed that modularization is truly powerful when done right.

Karl Bråtegren, Senior manager
Modular Management

Goals for the Modular Architectur

Strategic Goals

ABB Robotics launched a pre-study into modularity. It was initiated and conducted with the help of Modular Management, and inspired by the business success of a key customer, Scania.

This pre-study indicated that the company should be able to make strategic gains in sales as well as operations by implementing modularity. Complexity, as measured in unique parts, could be cut in half for several product lines and there would be many positive impacts on overhead, direct material and tied up capital cost. In addition, the management team concluded that with modularity it was a realistic ambition to deliver more and better products to ABB customers while improving product quality.

IRB 1100. The Most Compact and Fastest Robot Ever at Launch

Based on the promising results of the pre-study, the ABB Robotics management team initiated a modularity program covering all robot families, including software.

Yet since the competition was getting harder, ABB Robotics initiated a market analysis. The market analysis team was tasked to answer a fundamental question: which customer requirements should ABB Robotics strive to gain competitive advantages in?

A team of product and business line managers conducted over 100 customer interviews. The result was a customer segmentation model and product range specifications for the future modular products.

Product Scope and Goals

First out the gate were the robot controllers.
A cross-functional team used the findings from the market analysis and modular function deployment (MFD) method to create a conceptual modular architecture. Key product requirements were to:

• reduce the size of the controller
• deliver out-of-the-box intelligent safety and online service capabilities
• reduce direct cost
• reduce number unique parts to build the controllers
• enable controllers to be built by robots.

Modular, OmniCore Robot Controllers

Next up was the software used to program and move the robots. A team of leading software architects and system test managers attacked the structure of the current software. The ambition was to:
• move to a new software architecture that enables continuous release of features
• secure high independence from the hardware
• reduce bugs through upstream module level tests combined with fully automated tests of the most common functionality.
• improve the robot software overall to make robots more aware, smarter and connected.

Finally, two teams targeted robot arm modularity. Here the targets were to:
• create a technically more consistent robot arm architecture
• enable more re-use
• expanding the number of robot arm variants used for different applications.

Business Results

The results of the modularization program were significant.

Controllers

  • Number of different controller cabinet products increased by 300%
  • Unique parts cut in half
  • Size of smallest controller cut in half
  • All controllers equipped with intelligent safety capabilities, allowing removal of fences
  • All controllers ready for remote serviceability.

Software

  • Number of possible independent software development tracks were expanded from one to up to 80. ABB Robotics will scale to the number of development tracks that they see makes most sense for their customers and their own operations.
  • Level of fully automated tests are set to increase to over 90% of all test cases
  • Time to market of new features will be reduced to less than a month for many features compared to approximately half a year at the starting point.

Robot Arms

  • Product assortment expanded by over 50%
  • Number of unique parts reduced by more than 30%
  • Entire range of industrial robot arms built around only a handful of main layouts compared, which is less than half compared today.

Operations

  • Number of production lines reduced by 50%
  • Factory footprint of the new production lines to be cut in half compared to today
  • Production capacity quadrupled from 2013 level
  • Robots will be produced by robots assisted by humans in a mostly collaborative fashion.

And there were additional benefits.

According to Roger Kulläng, Global Software Solution Architect, ABB Robotics, “As software architecture can easily be circumvented by the coders, it is important to repeatedly go back and look at the reasons why certain functions were grouped into modules. We have done software modularity before, but this time we factored in customer values and strategy. I believe this makes our new architecture much stronger.”

If you are inspired by the ABB Robotics case and  interested in understanding  how your product architecture can benefit from a modularity program, please fill in form below and our specialist team will contact you to.

Contact us

HOT TOPIC

Software
Modularity

By Karl Bråtegren

SOFTWARE

How to Avoid Roadblocks?

Karl Bråtegren, Senior Manager at Modular Management in Stockholm, shares some thoughts on software modularity and how to avoid roadblocks.

KARL ON ONE OF HIS FAVORITE TOPICS

What is Software Modularity?

Software modularity is the decomposition of a program into smaller programs with standardized interfaces.

Microservices is a hot trend right now, and it’s essentially about small modules that are built into a whole software system. Spotify and Netflix talk about how they work with microservice architectures, and before this there was a similar trend called Service-Oriented Architecture (SOA) that targeted bigger modules.

Software modularity pretty much shares the same definitions as hardware modularity, with strategically- and functionally-clean modules that are driven by customer needs and share standardized interfaces. You basically allocate different functions to software modules and then implement them in source code.

A common way of referring to interfaces between software modules is Application Program Interfaces (APIs). For example, Google and PALMA expose APIs to the external world, and when you create software modules it’s like creating APIs within the product.

Why is This a Hot Topic?

The main driver is that software is rapidly becoming a bigger part of many products.

Software is delivering on the most important customer values and companies need to be much faster in development to stay ahead of competition. With modularity you can secure product leadership with separate modules that can be developed quickly without being locked into a complex web of other software functions. Basically, you can avoid roadblocks.

A second driver is ‘hardware portability’, a topic that many clients are looking at right now.

Hardware portability means that you want to be able to move the software solution from one hardware to another, enabling you to easily change hardware supplier. Electronics like PCBs, for example, can reach end-of-life quickly and you need to replace them. You also want to take advantage of better and cheaper hardware when it becomes available. If you have inflexible, over-dimensioned software that doesn’t scale well with the hardware, it makes it very hard to move the solution to a lower performance piece of hardware. With the right modules in place, you can isolate hardware impact to specific modules and enable hardware scalability and portability.

A third driver is that you can’t do everything on your own.

You want to make use of open source and leverage third-party specialist expertise. It’s much easier to plug in third-party software, for example navigation and vision processing, into a modular architecture than a monolithic one. You would in this case aim to create modules with the aim to source them from a strategic partner.

What’s Your Personal Experience of This?

We’ve recent client experience, but an older example is when I worked as Product Manager at Siemens Mobile Networks. This was back in the old days of Wireless Application Protocol (WAP), General Packet Radio Services (GPRS) in mobiles and slow networks.

At Siemens we didn’t have a WAP proxy to sell to operators and wanted to launch our own product. What we did was to partner with an American company that had a proxy server with compression technology, and they then made their APIs available to us. Using these APIs we could develop services aimed at the cell phone service providers and make a viable and attractive solution. We also discovered that we needed a WAP protocol stack, so we found a Finnish company with a commercially available WAP-stack that we could plug into.

This is a practical application of our strategic sourcing driver from the Module Indication Matrix (MIM), but at Siemens we didn’t think much about it back then. We just bumped into challenges that had to be solved and found a way to solve them with strategic partners.

What are the Opportunities for Companies?

There are many reasons to invest in software modularity, but it’s basically about being fast and flexible. By developing new features faster, and more frequently, you can provide new software and hardware products that better meet customer needs.

You can also work with the continuous release of new features, while maintaining quality and not putting product reliability at risk. In an integrated or monolithic architecture, there’s a risk that when you introduce a new feature update the whole product goes down. If it’s a robot, for example, this means the whole line stops. Even if the update feature is quite small, like a nice new Graphical User Interface (GU), customers will be scared – or won’t even dare – to update if it’s in a big monolithic package. This has been a real issue and in some cases it still is.

Without a flexible, modular software you have a slower development pace, more bugs, more testing issues and more time to release. You’re also forced to live with old and expensive hardware and run end-of-life hardware projects, often in panic mode.

MONOLITHIC AND MODULAR DEVELOPMENT HIGHWAYS

What is Modular Management Able to Offer?

We’re able to offer a unique approach in Modular Function Deployment® (MFD) which solves many of the challenges mentioned earlier.

I haven’t seen any other structured approach that explains how you should think if you want to move to microservices or a more modular software architecture. There are rules of thumb in the software world, like separation of concerns, but there is no real method like the one we have.

MFD is unique because it takes customer values into account. This is extra important for software, because for a lot of modules you don’t need parallel variants of the source code, you just need to increase speed in delivering on certain customer values. In other words, you need to rapidly bring out new versions of these modules.

With MFD you can also consider company strategy up front, for example hardware portability, strategic sourcing, carry over and technical specification. One scenario is that when you offer integration capabilities to the external world you may need different protocol stacks. An example of this is to offer many different industrial Fieldbuses (ProfiNet, EtheNnet/IP, DeviceNet…). They will typically come with their own variants of the code. This is an example of when we would apply technical specification as a strategic driver. In the end, this could be enough reason to create a module for the Fieldbuses.

Many of our clients typically have good technical software architects. Architecture is a skill that’s important when you work with software because it’s so abstract. You don’t have brackets and pumps to touch and feel, so software architects are typically comfortable in talking in functions and working with architecture diagrams. But they often overlook customer values and strategies, or at least don’t have a systematic method to approach these critical drivers and how to reflect them in the architecture.

THE CUSTOMER-CENTRIC METHOD FOR PRODUCT ARCHITECTURE CREATION: MODULAR FUNCTIONAL DEPLOYMENT (MFD)

Any Final Thoughts?

I’ve heard software architects say that it’s more difficult to describe exactly what you mean when it comes to software, just because it’s so abstract. You also have a very high degree of freedom in implementation since you’re not bound by physics.

This level of freedom makes it easier to circumvent the architecture during implementation, so it’s always important to go back to why you defined a module and make sure it’s implemented accordingly. That’s where we come in. 

For more information, contact me via the button below.

CASE

As software architecture can easily be circumvented by the coders, it is important to repeatedly go back and look at the reasons why certain functions were grouped into modules.

We have done software modularity before, but this time we factored in customer values and strategy. I believe this makes our new architecture much stronger.

Roger Kulläng
Global Software Solution Architect ABB Robotics
SOLUTION
MODULAR MANAGEMENT SPECIALIST

There are many reasons to invest in software modularity, but it’s basically about being fast and flexible. By developing new features faster and more frequently, you can provide new software and hardware products that better meet customer needs.

Karl Bråtegren
Senior Manager
Modular Management

PALMA®

This is the world-class solution for product management.

Standing for Product Assortment Lifecycle Management, PALMA is cloud-based strategic software to create, document and govern modular product architectures. With this unique structured approach you can design and document product architectures. You can also connect enterprise systems and secure business goals.

Built on an in-memory database platform, PALMA is faster and more capable than anything else on the market, so you can create configuration rules without coding, govern product architecture life cycles and create a business advantage.