8.5 Ericsson Mobile Communications AB

---

Ericsson Mobile Communications AB develops and manufactures mobile phones (so-called terminals). The development is geographically distributed at several sites in the world. Engineering functions such as software, mechanical, and hardware engineering are mirrored at all sites (e.g., in Lund, Sweden, in which the case is studied). The case studies development of PDM support in this organization.

8.5.1 PDM tools

Different development groups use their own specialized PDM tools, often integrated with the development environment, to manage their local development. They are responsible for making available the necessary support in terms of processes and tools. Sometimes this is achieved by means of global solutions used in common with many groups; sometimes it requires homemade solutions. For example, the electronics group uses systems managing their components in terms of CAD data and data about purchase and contractors; the mechanical group has a system for managing revisions of CAD files; the software group uses ClearCase to manage revisions and releases of source code.

Within Ericsson Mobile Communication, several global solutions exist for many domains and phases in the PLC (e.g., RM support). The support systems for overall BOM control towards factory are PRIM, GASK, ESTER, and others. PRIM is the product and document register for the Ericsson group. The BOM for the product and certain other important information such as the relations between the product revision and document version, frozen product revisions, and PLC status are registered in PRIM. PRIM is internally reachable worldwide. GASK is the common Ericsson group archive, internally reachable worldwide. ESTER is the tool for handling of exemption requests. The tool can only be used for nonconforming products registered in PRIM. The use of the tool is compulsory for products to be delivered outside Ericsson with nonconformity, but the tool can also be used for all products, projects, and operations if the product number is registered in PRIM.

8.5.1.1 Current support

PRIM and GASK are used after production release. PRIM is used mainly for the view as designed and SAP R/3 is used for as manufactured (see Figure 8.18). None of these systems are used as much as intended during the early development phase. According to the PDM group at Ericsson Mobile Communication, this is unfortunate. More effective use of these tools, particularly during development, would be of benefit to all parts. Instead, local tools are used and registration in global tools is performed late in the development process. Late registration can cause problems with unique identities of products and documents (e.g., an identity used for one product but not registered can be allocated to and used by others for another product, and much administrative work is necessary to correct this situation).

Figure 8.18: Information flow and tools used in the design and manufacturing processes. The following abbreviations are used: Design status (DS), production ready status (PR), design just started (DS-/PR-), ready for preproduction (PR1/DS1), product test doc (PRA/DS4), ready to be sold (PRA), and product revision information (PRI).

Ad hoc use of PRIM and GASK results in limited control of versions and their contents. When the product is released, all production documents and related information are stored in PRIM and GASK, but during earlier phases, before production and to some extent also for work done between releases, this information is often only available locally. Other design data is not stored in PRIM and GASK. The project manager thus has a considerable responsibility to retrieve and send the correct information to the producers and contractors, especially for early prototypes, before correct revisions are registered in PRIM.

PRIM was primarily designed for use in the management of the production of large and complex products such as AXE switches, rather than mobile phones. Complex and rigid rules define the process (e.g., how to release the product, which requires much manual administration and control). These rules also require much of the project manager and make the process too slow to cope with the short development cycles used. It can also be hard for the developers to see what is in it for them, and therefore they do not use them, even though the truth may be that they have gained a great deal using the tools. Another reason for not using the tools is the unfriendliness of the user interface.

An important functionality of a PDM tool is to provide awareness of the progress of a project to all developers and managers. This is best achieved if documents are checked in frequently and made accessible to others concerned. It is thus important to be able to check in work in progress, making it clear at the same time that it is in an unfinished state. This functionality has not been utilized in the process.

8.5.1.2 Improvements in progress

TTM Engineering Platforms at Ericsson Mobile Communication were, at the time of writing, developing a new graphical Web-based user interface on top of Metaphase, designated metaDoc. metaDoc is actually built on top of Collaborative Data Management (CDM), which is an Ericsson-specific layer on top of Metaphase supporting corporate basic standards (e.g., the rules mentioned earlier and all unique identification rules). The PDM architecture is shown in Figure 8.19. CDM is also under development, and only parts of the final functionality are currently provided. In addition to metaDoc, other interfaces are built or are planned to be built upon CDM (for example, an interface to Unigraphics).

Figure 8.19: PDM tool architecture.

The introduction of metaDoc is developed in two phases. In the first phase, metaDoc manages nonproduct documents only (e.g., meeting protocols and general specifications). In the second phase, the metaDoc will include building support for BOM and product documents management.

8.5.1.3 Future plans

The next phase of the PDM program has been initiated and is supposed to support BOM control. It also includes a reimplementation of CDM in order to make the rules less complex and easier to understand and use (i.e., adapt the BOM management to the short development cycles used). Ericsson Mobile Communication actually does not want to develop tools by themselves. Initiatives such as metaDoc are taken only because they could not find something similar at the market. If a vendor provides an adequate interface, they will probably use that instead. It would still be beneficial to integrate the overall PDM tool with the local tools used within each group. There are ongoing tests of an interface between Metaphase and Unigraphics, and, as described in Section 6.4, there is also work on interfaces between ClearCase and both Metaphase and eMatrix. These integrations assume continued use of PRIM in collaboration with other PDM tools.

8.5.2 Product modeling

Ericsson Mobile Communication uses two different ways to model their products: complete product structure, and product (rule) engine. Often, a lot of different products and product variants must be managed, even though only some of them finally reach the market. To create one product tree for each product would be ineffective, so instead a product engine produces the products, as depicted in Figure 8.20. A “super BOM” contains all components that might be constituents in a product configuration. The product engine then defines a lot of rules of how to combine these components to build legal products. Some rules define which components technically can work together, while some rules are more market driven (for example, a color may be reserved for a specific product). The rules do not define all possible configurations but only those that might be interesting because of different reasons. By adding rules to the engine, it is possible to test new products. However, it is more complex to manage rules than to manage relations.

Figure 8.20: Modeling the products by rules describing the products.

8.5.3 Traceability

All released products are registered in PRIM (i.e., the entire product structure is registered). Strictly bound configurations are not used, as this had resulted in too many versions, especially on the top level (i.e., the release number of the product does not exactly specify the revision number of all of its components). Full traceability is instead achieved through a generic configuration plus a five-letter code that really specifies its contents. The main reason not to use bound configurations is the large amount of manual administrative work they require in PRIM. Another reason is the need to be able to modify the product without changing its revision number. Customers are sensitive to new revisions, and it is hard to sell a product with an old revision number, irrespective of what the difference to the latest revision really is. The drawback of using generic configurations instead of bound configurations is lack of full traceability. Sometimes the only way to find the correct revision (e.g., to fix a bug) is to follow product revision information (PRI). A PRI describes the changes from one product revision to next product revision. The document is mainly used during the manufacturing phase to upgrade the hardware, as stated in the PRI.

8.5.4 Change management

There is no tool support for global change management. The software group has developed a tool called Fido, which supports the entire CR process and bug tracking. This tool makes it easier to find all products affected by a CR. A bug reported in one product may also exist in other products (e.g., a bug in a revision of a platform common for many products), and the CR created due to the bug therefore lists all affected products. Additionally those responsible for these products are informed through the tool. Fido is also integrated with the SCM tool used and is part of the freezing process of releases.

8.5.5 Conclusion

Ericsson Mobile Communications AB develops and produces many versions and variants of products, and the traceability of any kind is very important. Particular requirements require particular solutions in the development and integration process. This is the reason that the company has its special rules, procedures, and tools in addition to general and standard support from the corporation. The case study shows that in large organizations, very often the general support of the corporation level is insufficient, but local organizations need adjustments or other types of support that are specific for them. Further, the case emphasizes that there is a need for a permanent improvement of the support. This improvement will usually be incremental, acquiring the existing process into the new one.

The important need for support during the software development phase is elaborated in Chapter 3. A comparison of SCM and PDM functionality is made in Chapter 4. Issues regarding the deployment of new tools or functionality are discussed in Chapter 7.

---