8.4 Ericsson Radio Systems AB

---

Ericsson Radio Systems AB is a company within Ericsson AB. Ericsson AB is a supplier of a complete range of solutions for telecommunication systems and applications to services and core technology for mobile handsets. With the establishment of Sony Ericsson, the company is also a leading supplier of complete mobile multimedia products. Ericsson supplies operators and service providers around the world with end-to-end solutions in mobile and broadband Internet. The company supplies solutions for all existing mobile systems and future third generation mobile systems, in addition to broadband multiservice networks and broadband access. The solutions include network infrastructure, access equipment and terminals, application enablers, and global services to support both business and private communication.

This section contains two separate case studies from Ericsson, one from Ericsson AB (formerly Ericsson Radio Systems) and one from Sony Ericsson (formerly Ericsson Communication Systems).

8.4.1 The case study

This case study describes a project designated “Phase 10,” in which a product for the standard personal digital cellular (PDC) was developed at the Ericsson subsidiary Ericsson Radio Systems AB. The Phase 10 project was a large development project performed at design centers in Sweden, Germany, and Japan. This project has been finalized, and the product has been delivered to the customer. The complex product that was developed ( further called the PDC system) consists of a large number of subproducts, both hardware and software. The main project management group of 32 persons directed the work of hundreds of project members. The main objective of the Phase 10 project was to develop a packet data solution for the Japanese market, known as packet data PDC (PPDC).

This case study discusses the CM methods, the processes utilized in the project, and the support provided by PDM and SCM systems covering the PLC from customer requirements until delivery to the customer.

8.4.2 The PDC system

Figure 8.5 schematically depicts the PDC system and the subproducts implementing the PPDC product. The figure depicts how the public switched telephone network (PSTN) and data networks (ISDN) are connected to the existing switched network communicating via the gateway exchange (GMSC). Two more exchanges, a voice mobile switching center (VMSC) and a packet mobile switching center (PMSC), are the main constituents of PDC systems. Depending on the nature of the incoming input, voice, or data, the GMSC switches either to the VMSC or to the short message center (SMS-C). Mobile phones are connected to the base stations (BSs). The packet data nodes use IP communication. The nodes are connected to the IP backbone. Operation and support system (OSS)/network operational centre (NOC) integration is the integration between existing and new operational support. The packet data traffic and signaling toward the mobiles and BS from the PMSC are carried in timeslots over T1 communication links connected to the VMSC and further connected to the BS.

Figure 8.5: The PPDC network architecture.

Most products in a PDC system consist of both hardware and software.

8.4.2.1 Product structures

To manage products and subproducts, Ericsson Radio Systems uses a standard way for identifying and describing them. Each product has a unique identity and a list of product revisions. The particular document versions are connected to a particular product revision. To fully describe a product, four different views are used, called product structures. The structures are hierarchical and comprise different aspects of product information during its life cycles. Each product revision is described by a separate set of the tree structures. The five structures are:

1. Functional structure. Functional structure is the specification of product functions. The structure points to the functional subproducts at the level below and can also point to implementation products (e.g., hardware or software).

2. Realization structure. A realization structure describes a realization product with all of its realization components. Realization products implement the functions described in the functional part of the structure. This structure includes BOM, all documentation of a particular product revision, and manufacturing structure for particular products, such as a printed board assembly, magazine, and cables.

3. Project structure. This structure specifies the document structure, which lists all directive documents for the project (e.g., project specification, time schedule, configuration management plan, verification plan, and delivery plan). This structure can be linked to the level of the functional structure.

4. Sales structure or commercial structure. This structure contains all product packages (i.e., all products to be placed on the market).

5. Delivery structure. This structure gathers the product packages, defined in the commercial structure, depending on the specific order from the customer.

Figure 8.6 depicts an example of the five Ericsson structures and how they relate to each other.

Figure 8.6: Example of an Ericsson product structure.

Three of these five structures (functional, realization, and commercial) are used for the PDC system. The product structures are registered in a product information management (PRIM) system, which is developed internally. PRIM contains product structures and document identities. Documents themselves are archived in a document archive system designated general archive system for communication (GASK). PRIM and GASK are described in Section 8.4.5.

Besides the functional structure, mechanical assemblies (e.g., processor, telephone, and packet data) are included in a structure separate from the basic function modules. This is done to reduce the size of the functional structure. Mechanical assemblies have no direct connection to system functions. Furthermore, products such as batteries, special cables, and antennas at customer sites are not included in this overall product structure.

8.4.3 Project organization

A project organization at Ericsson Radio Systems is a temporary organization, separate from the regular company organization, and established to execute a particular project. The project organization is grouped according to three organizational functions: a project steering function, a project management function, and a project executing function. Several groups realize each function with different responsibilities, as depicted in Figure 8.7.

Figure 8.7: Generic project organization and roles in a large project.

The groups realizing the steering function consist of managers in the organization with the authority to provide the project with management support and the resources needed for successful project completion exercise. A special member of the steering group is the project sponsor, who is commercially responsible for the project. He or she decides what is to be delivered, when and why, and what will be the development and maintenance budget. The sponsor has the main responsibility to initiate the project. In large projects, there may be more than one sponsor. The project steering group is usually formed when the decision is made to execute the project and is dissolved when the project has been concluded.

The groups realizing the project management function are responsible for managing the project toward its goal. These groups are established on the initiation of the project, when the responsibility for planning and executing the project is formally handed over to the project manager. The authority granted is limited to the lifetime of the project. The manager of large projects may appoint one or more project staff members as deputies. Depending on the scope of the project, these can be project managers on different levels: total project manager, project managers, and subproject managers. The project managers’ tasks are the same, independent of the magnitude of the project, but the size of the project, its complexity, and strategic importance naturally put different demands on the project manager’s competence and skills.

The groups realizing the project executing function are responsible for executing the project in accordance with the specifications developed by the project management function and for ensuring that the processes, methods, and standards of the organization in which the project is executed are adhered to. These groups are composed of personnel from the line organizations. Having performed the work required of them, they return to their respective line organizations. The purpose of establishing a project organization, in which the relevant stakeholders are identified, involved, and integrated, is to ensure that the authority and competence needed for the successful execution of the project are available for and contribute to the project. The Phase 10 main project is organized in the manner described earlier, as depicted in Figure 8.8.

The group members in “Project Staff” are responsible for general project support and are involved with the persons responsible for carrying out project activities (e.g., designers, CM managers, and system test managers work with designers, developers, and testers). This demonstrates the importance of integrated information systems providing accurate up-to-date information. The subprojects were geographically dispersed. Subprojects in the project organization of particular interest include:

• Test configuration management (TCM), responsible for supplying other design subprojects with test beds for function test;

• System integration and test (SIT), responsible for the integration of other network products and the packet data.

The very first release of the final customer product is delivered directly from the project to the customer. This delivery is called first office application (FOA). Other supply services are managed through the deployment project (not included in the development project).

Figure 8.8: Example of project organization from the PPDC product line.

8.4.4 PLC process

The PLC process used in Ericsson Radio Systems is divided in three subprocesses: time to market (TTM), time to customer (TTC), and maintenance and support. These processes are illustrated in Figure 8.9.

Figure 8.9: Time-to-market flow for PDC systems.

TTM spans from customer input (several other inputs may also exist) to the delivery of the product design. It contains product management, design, and marketing processes. Marketing activities and the design process are normally concurrent activities during TTM. In the Phase 10 project, however, the situation was different, as there was one single customer (i.e., the input to the project was one single contract). The TTC flow is the manufacturing process from the final design to the delivery of the final product. The maintenance and support flows are parallel with TTC. These activities start up before the actual product is delivered. This is done to prepare and educate the help desk and repair center before any customer enquiries exist or products need to be repaired. This PLC is well understood within the project, which is an advantage for implementing system support.

8.4.4.1 Maintenance

After product release, the product is handed over to the local Ericsson Company for service (first-line support). Second-line support (support of firstline support and coordination with maintenance) is normally managed within the design and maintenance organizations. Development, maintenance, and second-line support are located within the same organization. Product corrections are all delivered through ongoing development projects and therefore no separate fault correction releases need be managed.

8.4.5 The most important tools

Within Ericsson, hundreds of different tools are used during the products’ life cycles. Certain tools are used over the entire company. Also, some tools are used more often, especially in distributed development environments. Such tools manage product data, archives, and requirements management. They are described next.

8.4.5.1 PRIM

The PRIM is the central Ericsson product catalog, in which all released products and related documents are registered. Although other systems are used locally elsewhere, only PRIM provides global access to the unique number of every product. This is the only comprehensive product register within the Ericsson group. PRIM has four different subsystems that contain different kinds of basic information. These four subsystems are (see also Figure 8.10):

Figure 8.10: The four different subsystems in PRIM.

1. Product data providing basic information about products, such as product name, number, revision number, function designation, design responsibility, revision state, design status, release status, and production status;

2. Product structures providing present and historical information about the product structures through the delivery level, down to raw material and components;

3. Document data providing basic information about documents (e.g., where the documents is stored, or archived, who is responsible for the document, existing language codes, and version status);

4. Information structure providing all information that is related to the specific product.

Because many different tools are used during the development phase, products may not be registered in PRIM until they are ready for release. Within Ericsson, there is no other global product data management system with the necessary interfaces to other systems used in different development projects. According to Ericsson Corporate Basic Standards, all released products must be managed in PRIM.

8.4.5.2 GASK

The GASK is the central document and software archive within Ericsson. Ericsson Corporate Basic Standards demands the use of GASK for documentation of released products. Other tools or archives are available for use during project execution, but the GASK’s security and global accessibility make it the most suitable for use in a distributed development. GASK is used in the same way as PRIM; the information is stored at the release point or other project milestones.

8.4.5.3 Documentation environment library and transfer aid

Documentation environment library and transfer aid (DELTA) is a project archive tool used in many development projects, especially for the development of the public telephone exchange (AXE) system. Originally, it was a stand-alone tool, not integrated with PRIM or GASK. DELTA has an interface to PRIM, the DELTA Access tool. DELTA Access is a Web document management tool with access to DELTA to search, edit, print, and store documents. DELTA Access can be used to fetch, browse, save to disk, and print documents in GASK.

8.4.5.4 Modification Handling System

The Modification Handling System (MHS) is an old Ericsson-built in-house tool for modification handling. This is an error reporting system that contains functions to register and track errors and many other functions. Global availability and an existing infrastructure are the main reasons for using MHS. Although the system is old and often referred to as due for replacement, it is still used, especially during and after system test. During the development phase, other tools for error reporting are used (e.g., ClearDDTS and ClearQuest). However, not all projects use these tools. For example, in the Phase 10 project CRs are manually managed.

8.4.5.5 DOORS

Requirement management and the satisfaction of demands for traceability are increasingly supported by means of tools. Within Ericsson, DOORS has demonstrated its ability to manage a large volume of requirements of a high degree of complexity. DOORS was used within the Phase 10 project.

However, the requirements were still verified manually.

Other tools used alternatively for requirement management within Ericsson are eMATRIX, Requisite Pro, and Requirement Traceability Management (RTM) [2]. However, these tools are not used globally on the corporate level.

8.4.5.6 ClearCase

ClearCase is the SCM tool used on the corporate level. The multisite functionality is especially used when geographically dispersed teams develop a product. Once every night, all information is synchronized. To minimize risks and problems regarding naming, branching, and merging, a common methodology has been developed and used.

8.4.5.7 Tool integration

Prim and GASK are tightly integrated. If a document is stored in GASK, gthe information structure and document attributes are automatically updated in PRIM. MHS has an interface to PRIM. MHS does not accept error reports from products not registered in PRIM. Today, there are integrations between FrameMaker and GASK, Word and GASK, and Excel and GASK to provide storage of documents. The DELTA has an interface to DELTA Access but no other tool. The requirement tool DOORS has no integration to other tools. There is an interface between ClearCase and PRIM, with updates to the information structure in PRIM directly when changed. In some organizations, ClearCase is used as an archive with connection from PRIM (i.e., PRIM has a link to actual ClearCase installation where all documents and source codes are stored). No information is directly fetched from PRIM into ClearCase.

8.4.6 CM methods

The CM methods applied in the Phase 10 project were well defined and understood. The CM methods used within Phase 10 are shown in Figures 8.11 and 8.12. Figure 8.11 depicts schematically many baselines created during the project. Each baseline contains a report including the following documents: minutes of the CCB meetings, TRs, CRs, audit reports, and test reports. All of these documents are registered in PRIM and stored in DELTA. When the products are ready for release, all documents are stored in GASK. Each baseline always documents the four CM corner stones: configuration, quality, deviations, and decision.

Figure 8.11: The baseline content.

The flow of a CR process is shown in Figure 8.12. The product management or a member of the project team can introduce a CR. This CR will be posted to the mailbox of the CCB and also stored in DELTA. New CRs will be added into the CR log, which contains all information related to the CR. The CR log is presented and prepared by the local CCB. The main CCB will then make a decision whether to include the CR in the implementation process.

Figure 8.12: The CR flow.

These illustrations may indicate that all of the necessary methods were available to keep the product information for the Phase 10 project accurate and complete. However, the local tools supporting the methods were not state of the art and not integrated with each other. This required many manual activities, which may be a source for introducing faults.

8.4.7 Information flow

Figure 8.13 is an overall illustration of the project information flow, involving the tools needed. This is a generic picture at a very high level, intended to depict the basic flow. In a complete flow, many other tools are involved.

Figure 8.13: Overview PPDC information flow.

Customer requirements are registered in the tool PEACE. New requirements generated either by product management or project team members are stored and managed in the requirement tool DOORS. A main requirement specification (MRS) is written and updated from DOORS and stored in the project archive DELTA. The MRS will be used for design for new or changed functionality. During the design, the different archives depend on the product developed. The design documentation is stored in the common archive GASK. Deliveries are stored both in a local archive, and the software for AXE archive (SWAXE). PRIM contains the product structure and is updated with the latest information. When the design is ready for a function

test, it will be fetched from the different archives GASK, SWAXE, and PRIM. Builds will be temporarily stored on local file servers. When a system test is performed successfully, the product is ready for FOA or deployment. Customer product information will also be produced. This information [e.g., document products for AXE (DWAXE)] is fetched from GASK, refined, and stored in the archive Active Library Explorer (ALEX) before delivery to the customer. ALEX is designed to handle electronic documentation and provides a user with the means of browsing in document libraries with a standard Web browser.

Figure 8.13 indicates the problem of establishing flow control and traceability. With many tools and many interfaces, the possibilities of accessing correct information from involved systems are reduced. Today’s project management is hampered by the lack of an overall PDM system.

In the text that follows, a more detailed generic description of three major phases are presented: RM, software and hardware development, and build management. The purpose of these is to explain the backgrounds of the tools and to give the reasons for their use.

8.4.7.1 RM

The customer requirements are processed by local Ericsson companies. The local product management is responsible for discussions and agreements on contract issues. The Ericsson office then communicates with the Phase 10 project requirement coordinator in Sweden. The coordinator is a representative at the main project level of the product management in Sweden. Study of the requirements will be assigned to one or more of the three major research and development organizations. Figure 8.14 is a part of Figure 8.13, focusing on the flow of requirements from the customer to the start of the development phase.

Figure 8.14: The requirement flow in the product specification phase.

The requirements from the customer are stored in the PEACE database at the local Ericsson Company and also in the global DOORS database at Ericsson Sweden. All requirements for all PDC systems are stored in DOORS.

All relevant requirements for the Phase 10 project were assembled in a report from DOORS designated MRS. The MRS is stored in the project archive DELTA. The requirements are controlled in a baseline (so-called requirement baseline) and changes are managed with CRs. However, as the different requirements are described in an ordinary document and stored in the project archive (DELTA), it is possible to update the document without issuing a CR. Such changes will not be visible in the requirement baseline. The requirement baseline and the CRs are managed manually without tool support.

A number of improvements in the process can be made. For example it should not be possible for project team members to update requests without writing a CR first and following the CR procedure. CRs should be visible together with their corresponding requirement. Furthermore, requirements should be linked or tagged down to test specifications for full traceability of each requirement in the whole system. The requirement baseline should be the only source of requirement information.

8.4.7.2 Software and hardware development

Information flow of software and hardware development is shown in Figure 8.15. The requirements phase of the project is common for software and hardware development. The software development phase is, however, separated from the hardware development process. The software product is developed on the basis of the input from the requirements specification and product specification process stored in DELTA. The software produced during software design is stored in different archives depending on the design organization and product (e.g., ClearCase or local archives). Various software-programming languages are used. AXEs use the internal Ericsson language PLEX. The PLEX language has been used since the 1970s, and the supporting tools have been modernized during the following years. Traditionally, all source code has been stored in GASK. Modern languages, such as C++ and Java, are also used within software development in Ericsson. In some organizations, code is generated directly from UML. In recent years, the use of ClearCase for software configuration control has expanded. When the design is ready, the code is archived in an approved archive (i.e., GASK for non-PLEX language and SWAXE for PLEX language). All documents written during software development are archived in local archives. All product documents are stored in GASK. Metadata and files are stored in different archives in different locations. This emphasizes the need for an integrated environment.

Figure 8.15: Information flow for software and hardware development.

Hardware development is much more mature with respect to common methodology and tools in comparison with software. Usually, system studies on functional block level identify the need for a new or updated hardware product. The study specifies the requirements and the specification of the hardware units. The prototype is designed in a CAD environment. When function tests have been performed, the realization phase begins. A hardware design environment helps to adapt layouts to approved standardized boards. The planning of production begins at an early stage in a development project. If needed, the printed board assembly (PBA) is manufactured in a preseries production for testing properties and function. A trial production run is then performed to obtain measurements of the costs and time of common manufacturing. These measurements are compared with the stipulated requirements, and, if acceptable, the production unit approves the product as ready for production. Information prepared for the TTC process is exported from PRIM and GASK to a global order inventory invoicing system (GOLF) database. GOLF is an order system used for the management and administration of customer sales orders. It helps untangle the order management problems from order processing through invoicing, purchase administration, and stock reporting. GOLF keeps track of stock movements, incoming orders, order adjustment, order stock, and invoicing.

Figure 8.16 shows the overall flow for hardware design. Mechanical parts and cables have been traditionally considered within Ericsson as nonsystem-dependent products. Most often, the PBA and software are structured into function blocks defining the needed software or hardware modules for a certain function. Mechanical parts, cables, batteries, power supply, and cross connectors are structured in a separate structure or separate branches of the functional structure.

Figure 8.16: Information flow for hardware design.

While the hardware development process is rather smooth, several things can be improved. For example, there is a lack of traceability of requirements from the top level. Further decomposition of functions is not supported from CM. A function cannot be unverified as a CI (i.e., it is not possible to check out and check in a function). Finally SCM-PDM integration is missing. To further support the development environment, Ericsson focused on use of the PDM system Metaphase. Also, Ericsson has initiated a project to obtain integration between Metaphase and ClearCase.

8.4.7.3 Build and test management

The build process is centralized. During the later stages of development, all relevant information is collected at one site where the system is built (and some basic tests are performed). This build is then distributed to all subprojects, where it is tested and further developed. In detail, this process is much more complex. When development is completed, the software is sent to a test CM subproject. The test CM prepares a test bed (dump) for other subproject testing. The project deliverables are stored in SWAXE (the PLEX software) and in GASK (software written in C++). Function tests can be started when the test bed is available. The software is also delivered to the subproject SIT, in which the AXE system is integrated with the packet data part. From this phase, all errors are reported as trouble reports in the MHS, a common tool within the Ericsson group worldwide. Customer product information documents are fetched by DWAXE from the archives Delta and GASK. The documents are updated and stored in the archive ALEX. When products are released and documents are approved, all customer product information documents (for operation and maintenance) are translated into the languages of foreign customers. The customer orders hardware directly via the GOLF system. Information flow of the entire build and test process is shown in Figure 8.17.

Figure 8.17: Software program and document library production.

When function test is finalized, the system test begins. When the system test is finalized, the system is ready to be sent to the FOA and deployment project. The most important system here is, once again, the error report system MHS.

As seen from the figure, the build procedure has a rather complex information flow. Also, there are many manual procedures. For example, it is not possible to perform a fully automatic daily build of changed products or their parts. Neither it is possible to automatically create reports of the delivery (e.g., the content, the included solved TRs that are corrected, known errors, the included requirements, and the list of new features). The test environment still lacks automated tests.

8.4.8 Conclusion

In the Phase 10 project, there was a good understanding of the clearly described PLC and the configuration methods were up to date and competitive. The basic CM methods and the necessary “know how” and “know why” were available. This provided promising prerequisites for a successful process implementation by using PDM and SCM tools in an integrated environment. However, the total number of tools in combination with their poor interoperability interfaces made the work dependent on manual procedures. The major comments of the project CM manager are related to the lack of adequate tool support. Ericsson is making efforts to change this environment and has projects ongoing to introduce the PDM system Metaphase integrated with ClearCase.

We can summarize the conclusion with several comments:

• Ericsson Corporate Basic Standards provided a good basis for PDM.

• The global systems (PRIM, GASK, and MHS) were of great assistance in this distributed development project, especially during and after system test.

• SCM was well implemented.

• The life cycle model was clearly identified.

In addition to these positive comments, there is obvious place for improvements:

• Far too many of the systems involved were without interfaces and interoperability.

• Too much manual work was required, because of the absence of PDM for the described flow and because PRIM and GASK are old tools soon to be phased out.

• In general, CMtool support for all phases up to system test was weak.

• Generic CM support suffered from the lack of tools linking CRs to baselines.

The importance of supporting the entire PLC is discussed in Chapter 5. Issues about interfaces and interoperability between tools are can be found in Chapter 6.

---