The present invention relates generally to systems and methods for software integration and factory deployment of the software.
Producing consumer electronics and in particular computers that might incorporate, in addition to operating systems with various configurations and suites of applications, several subsystems, each in turn with their own software drivers, can be complicated. Not only must a bill of materials (BOM) be defined, managed, and conformed to, but product defects and corrective actions must also be managed in way that ensures corrective action can be known and taken across the globe.
Because of the complexity inherent in the above considerations, it can happen that more than a single management system might develop over time, complicating efforts to integrate knowledge and data. As recognized herein, it is desirable to have a management system that can integrate the knowledge and input of designers, engineers, software integrators, etc. in ways that reduce engineering lead times and provide ease of tracking defects and cures to the defects in a single, globally shared system within an enterprise, while providing an easy way to manage regional differentiation of software offerings, sharing information between business groups within the enterprise, and eliminating duplicative data maintenance.
For example, many computers are sold on a configure to order/build to order (CTO/BTO) basis. Each software part can have a multidimensional relationship with each stock keeping unit (SKU) that represents a product when region, language, various operating system versions, and platforms are factored in. Thus, each software part can potentially have dozens of version releases to accommodate all of these variables. As but one example of the complexity of providing CTO/BTO computers, one version of a “click to DVD” software may be used only on French Windows MCE SR series SKUs that are sold only in Quebec, but another version may be designed to work on any model using Windows XP Home Edition Spanish Version regardless of region.
As another example of complexity, consider that there are currently about ten Sony VAIO platforms worldwide, and each platform may contain multiple VAIO models with variations on CPU, RAM, HDD capacity, wireless (WLAN, WWAN, and Bluetooth), graphics chipset, etc. Several major regions that include an even greater number of languages in many different countries, along with plural operating system variations, may require support. Still further, each model of VAIO for each region/language/country/OS variation contains well over one hundred pieces of software, each of which may be a unique version for only that model, or may be used for multiple models of VAIO, giving an idea of the exponential scope of the relationship between software and computer models the database must be designed to support. In summary, the relationships between software parts and the platforms they are used on have become extremely complex, and with this critical recognition in mind, the invention herein is provided.
In addition, the present invention critically recognizes that the quality of the final product is important. As understood herein, each piece of software may contain defects, or when combined in an image with other software may cause defects to be generated.
As set forth further below, processes and tools are provided herein for quickly assessing the quality of a project by relating the defects to part releases, which are in turn related to projects. For example, if a major flaw is found in a particular release version of a part, this defect is related to the appropriate part release or releases so that the defect is instantly related to all the projects that use the particular part release. Given the complexity of the software BOMs, without the present invention this task would be difficult and time consuming to do manually.
Thus, preferred implementations of the present invention correlate the relationships between software parts, the platforms they are used on, and the quality of those parts.
A method is disclosed for managing computer production in an enterprise. The method includes receiving a block of software offerings, with each block being associated with at least one product series. A product series component structure is received that defines parts for a respective product series. Parts that are required for a product series are added to the block associated with the series, with parts being assigned to each software class and related software specification pair in a block based on the part or parts required for the pair to thereby define a design structure. The method includes establishing a software bill of materials (BOM) based on the design structure using a template and/or a snapshot.
In non-limiting implementations the method includes defining software offerings. A software offering includes at least one software class and at least one associated software specification. Software offerings are associated with respective product series to establish a configuration, with configurations cumulatively defining a configuration range that contains product offerings of the enterprise for all regions in which the enterprise does business. The method may include grouping classes into blocks. A block is associated with at least one product series.
The non limiting method may also include defining which classes are dependent on each other, and defining which blocks are base blocks. Defects can be associated with related classes and corrective actions associated with respective defects.
If desired, the method can includes associating a respective installation file with each software offering. Each installation file may include a data file format version number, a version number of an installation data snapshot, an installation order for modules, data required for confirming successful installation, cyclic redundancy check (CRC) data for each binary file, path information thr locating files in a file store, partition size information for recovery and customer partitions. Also, installation anal recovery tools may use a list of software releases directly instead of microcode, which is used only for customer recovery, with microcode bit mappings being constrained to respective recovery media sets.
In another aspect, a software management database on a computer readable medium can contain data structures supporting computer software provisioning for a range of CTO/BTO variations, language variations, region variations, and operating system variations.
Non-limiting data structures may include bill of materials (BOM) entities containing information related to parent BOMs and child BOMs, if any. Each BOM entity can also include an engineering part ID, a software release ID, a major version ID, a group ID, a component ID, a planning parts ID, and a software series ID. A plan parts entity can also be provided that includes launch dates for software base releases, import dates for software bases indicating when the bases were imported into computers, and identifications for software bases.
Other non-limiting entities in the database may include component entities including launch dates for software base releases, import dates for software bases, identifications for software bases. Software release entities containing a base ID, a name, a file path, a launch date can also be provided, as can be software release status entities that include data representing status and name of a software release. Additional database entities may include: a group entity containing data representing a name and launch of a type, a series entity containing a software series ID, base ID, name, an indication of being active, a launch date, an import date, an engineering parts entity containing an engineering part ID, a base ID, a type ID, a name, a launch date, and indication of dependent parts, an engineering parts major revision entity containing information related to default use, an engineering part software release entity containing information on a related engineering part entity, a related engineering parts major revision entity, a related language code entity, and a language entity containing information related to a language name and a language code.
In another aspect, a computer-implemented system for creating bills of materials (BOMs) includes logic that can be executed by a computer and stored on a computer readable medium. The logic facilitates creation of BOMs using templates and/or snapshots. BOMs can be automatically generated based on part attributes and groups of parts, major versions, and releases. The logic can automatically check BOMs to reduce errors.
In still another aspect, a computer system executing logic stored on a computer readable medium enters, into a first database, first software data. The first software data includes operating systems and configure to order build to order (CTO/BTO) options. The system transfers at least some of the first software data in the first database to a comprehensive global database, referred to herein colloquially as “ePic.” Second software data such as operating system updates, device drivers, and utilities is automatically adding to a bill of materials (BOM) through the comprehensive global database. Also, software along with metadata that describes the software can be checked into the comprehensive global database by users, and the BOM for a specific series/language/region can be frozen/locked and the process to create factory deliverables including software image, software modules, and data can then begin.
The database tracks defects and relates them to parts, stores test cases which are related to parts which in turn allows test strategies to be auto-generated.
The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:
In the present non-limiting implementation, only part of the software data is contained in a data store referred to below as “DB Hero”. Specifically, software data that is visible to customers (e.g., operating systems, configure to order/build to order (CTO/BTO) options, software highlighted on web sites, etc.) is entered into DB Hero. As set forth in the specification below, periodically, some of the data from DB Hero is pushed to a comprehensive global database referred to herein as ePic, including both stock keeping unit (SKU) data and software data.
Software data that is not as visible to customers (such as operating system updates, device drivers, utilities, etc.) are added to the bill of materials (BOM) through the comprehensive global database. Software is checked into the comprehensive global database by developers, vendors or engineers, along with metadata that describes the software for process tools. The BOM for a specific series/language/region is frozen/locked and the process to create the factory deliverables (software image, software modules, and data) can then be started. As set forth in the detailed specification below, various process tools and manual process can be used to create the factory deliverables, all of which use data stored in the comprehensive global database.
Additionally, the factory deliverables are tested and validated to meet quality standards. The factory deliverables, and the metadata that describes them, are then delivered to the factory to be used in mass production.
To better understand terms used herein, the range of potential software offerings for a given sales cycle is defined as a set of classes and specifications. The class structure captures how the various software items will be offered to the customer, and is a specific type of software. Specifications, on the other hand, are individual software items that are associated with classes. Thus, a specification is an option that the customer may choose within a class, and a class may have more than one specification while a specification is assigned to only one class. Software offerings (classes and specifications) are associated with individual series, with the resulting structure being called the “configuration range,” The configuration range for a SKU is a list of all the Classes (and specifications) that are offered for that SKU.
By way of non-limiting example only, a “class” might be “pre-installed office software”, and specifications within that class from which the customer can select might be “MS Office professional”, “MS Office Small Business”, “MS Office Basic”, and “MS Works.”
With the detailed description below it will be appreciated that the database herein supports software variations in CTO/BTO, language, region, and OS. In addition, this database, and the tools that use it, allow for the creation of CTO systems, based on individual customer orders, in the mass production process with every piece of software preinstalled and ready to use, allowing for a virtually infinite number software offerings to customers as opposed to a few pre-defined options.
Also, unnecessary duplicate data entry is eliminated, hardware components are automatically mapped to software releases, and developers can specify language and geographic region supported for each software release at the time of software check-in, with the correct release being assigned to each BOM automatically. Further, BOMs are created using templates and snapshots for efficiency. Moreover, BOMs are automatically generated based on part attributes to reduce effort, and groups of parts, major versions, and releases can be defined and reused. Automatic checking of the BOMs is provided to reduce errors. In addition, installation and recovery tools use a list of software releases directly instead of microcode, which is used only for customer recovery, with microcode bit mappings being constrained to each recovery media set that is defined. This solves the problem of limited microcode bits and makes the changing of a recovery key easier.
Below are details of one non-limiting implementation of present principles,
Referring briefly to
A human language and/or geographic region is selected at state 24 and then based on the selected language and region, at state 26 a processor in one or more of the enterprise computers 12 shown in
The software integrator then selects the image or module to be built at state 28, and at state 30 a BOM snapshot from a list is selected for the part selected at state 28. In response, a processor in one or more of the enterprise computers 12 shown in
A detailed description of a non-limiting implementation of the invention follows below.
The Software Integration and Factory Deployment Project solution will operate within the context of the new design process specified as part of the DB Hero project.
1. Software Planning and Design
2. Software Development
3. Software Integration
4. Release to Manufacturing
5. Download installation data, images, and modules to factory
The process outlined in the non-limiting diagram of
The process definitions are tailored to capture details relevant to SIFD only. Details of the hardware design process are not captured here.
This process describes how the software and hardware design processes are integrated in DB Hero.
1. Define Series
2. Identify Software Offerings
3. Define Classes and Specifications
4. Define Planning Level Parts (e.g. royalties, catalogue, etc.)
5. Define Offerings Structure and Constraints
6. Define Block Structure
7. Confirm Component Structure
1. Transfer Parts and Series info to ePic
2. Planning BOM Creation
3. Define engineering image and module parts as required
4. Associate planning level parts with engineering parts
5. Define image & module contents where required
6. BOM Confirmation
7. Transfer Component BOM to ePic
8. Create Series Software BOM
1. Register DB Hero Part
2. Transfer Parts to ePic
3. Register Part (ePic)
4. Associate Planning Parts with Engineering Parts
5. Develop Software Module
6. Check-In Software Module
ePic System Interlace can Engage Each Regional Build Tool Implementation.
1. Extract Build Info
2. Build Image
3. Check-in Image
1. Release to Manufacturing
2. Generate Installation Data File
3. Notify Factory Engineers
4. Download Installation Data File
5. Download Image and Module Files.
6. Place order (NOTE: This step does not involve interaction with ePic. It is depicted here to show the order process relative to factory deployment for a CTO sales process).
7. Install Software
8. Deliver Log data to GARATA
This section describes how running changes would be issued using ePic. This is the VOA EPC process adapted to ePic functionality.
To facilitate, review and implement any Engineering Processing Changes (EPC's) to projects after initial RTM has been issued.
EPC-A: A running change in which existing software on the Series Software BOM RTM snapshot is patched in the manufacturing process. These are deployed as modules of type EPC. There are two types of EPC modules:
The installation process and tools will be common for all QA, Factory, and Recovery applications and is in reference by the non-limiting process of
1. Generate Software Release List
2. Generate Recovery Key
3. Write Recovery Key to DMI
4. Partition Hard Drive
5. Copy required file to recovery partition (HDD Recovery Only).
6. Prepare Customer Partition(s)
7. Generate Log Data
1. Define recovery media engineering parts.
3. Create Recovery Media.
ePic will interface with many systems and tools. This chapter summarizes those interfaces.
1. DB Hero
2. Image/Module Build Tools
3. Test System Preparation Tools
4. Media creation Tools/Systems
5. VELSUN
6. VALSUN
7. ESG
8. OASIS
Several components external to the core ePic system will be developed by Neusoft, VOA, and VBD to facilitate these system interactions. Detailed requirements for these components are captured throughout chapter 9.
The following terms are important for understanding requirements in this section. Additional terms are defined in chapter 13.
Requirements that apply to all aspects of the system are listed here.
Each instance of an entity can also have an “owner list”. Users with permissions to create/edit and entity can add other users to the owner list. Users on the owner list can edit that instance of the entity regardless of their assigned system role(s).
These are requirements for the “high-level planning” functions implemented in DB Hero that impact STD. Only business rules or functional requirements which are necessary to ensure proper STD functionality are captured here.
Requirements for the “low-level planning” functions and software BOM creation in ePic are listed here.
The following is a graphical representation of an ePic Engineering Part to help readers understand requirements:
ePic requirements to support developers who use the system are listed here.
The detailed format for software modules is documented separately in a “Modular Specification”.
ePic requirements to support integrators who use the system are listed here. ePic will provide a single interface to build tools. Each regional group is expected to modify their build tools to work with the new interface.
Functionality specified here is to be used by integrators as part of image creation and Series Software BOM creation. Functionality to manage DB Hero SKU's and associated BOMs and create dummy SKUs and BOMs is also included here.
This section captures ePic requirements specific to factory deployment. Some of these requirements extend previously specified functionality. The requirements and data format for the installation data file is captured in section 9.8.
5.6.4 interface Requirements
5.7 Installation and Recovery (ePic)
These requirements describe ePic functionality required to support software installation and recovery.
As part of the requirements process global modular and recovery specifications will be defined. These requirements describe changes that must be made to US installation and recovery tools in order to work with ePic. These tools will become the global Installation and Recovery Toolset.
5.9.2 User interface Requirements
The following key concepts are central to ePic Test Management and Defect Tracking functionality:
The following predefined reports must be provided by ePic. Samples can be found in the appendix (chapter 13.3)
The following events will trigger email notification to users. On screen notifications are indicated elsewhere in this document.
9.14 ePic Interface Library
This section describes requirements for the ePic database interface library API for Build Tools and Test System Preparation Tools. Some interface requirements and tools requirements in other sections of this document are satisfied in whole or in part by this API.
VOA tools covered are Magellan and Modular Image Network Download System (MINDS).
All VOA build tools use ePic data, but most of the tools use flat files created by Magellan, as the source of data. Build tools also check in software releases and images and thus need to be able to write data to the ePic database and upload files to the file store.
VOA test system preparation is performed using MINDS tools. These tools are provided on a WinPE CD. This toolset will be made available to ePic users.
SDNA will use VOA provided build tools.
9.14.1 ePic Database Interface Requirements
The ePic database interface should provide the following functions. When a “Recordset” is specified as return value, all applicable attributes for the entity should be included in the Recordset.
9.14.4.1.1 Download Image to Test System from MINDS CD.
This section describes requirements for ePic from the Global Sustaining Group. These requirements will extend existing functionality.
Moving to
The following table lists the LangRegions to be used initially.
For the attributes listed as “required” in search columns, only one of the required fields must be specified by the user.
Some attributes are duplicated between Engineering Part and Release: The attributes set for engineering part should be used as defaults when creating a new release. User can override values set for engineering part at the release level. This function is intended to reduce repetitive data entry due release check-in.
Now referencing
As a global system, More than six places are involved in ePic network:
EPic will be rolled out in two phases.
Phase 1 Requirements will include the following ePic functionality:
Phase 2 Requirements will include the following ePic functionality:
VOA tools will be adapted to become the global recovery and installation tools. The release date for these new tools will be timed to coincide with the phase 2 release.
Build system modifications must be completed by VOA, VOE, and SDNA in order to build images and modules with ePic.
Plans for implementing and testing changes to build systems must be made the following milestones in mind:
Current Tools and Systems
Changes to Tools & Systems
Current Tools and Systems
Changes to Tools & Systems
Three regional build tool implementations must be modified to work with ePic. Objects created by each regional build system may change to comply with the global modular and recovery specifications, which are to be defined as part of this project.
This section lists current build system artifacts from each region's build system and mappings to ePic fields. The ePic fields listed below are detailed in Section 10.4 of this document. Note that in some cases the format and meaning of the attribute may have changed from the current state. For example, Software Release ID (formerly ESP #, SITID, etc.) will now be an integer with a prefix denoting part type (this will necessitate changes to all three build systems).
Architectural note:
Build Tools create the following objects:
MScript.INI: Contains all items on Module BOM.
VSMS Fields used: Same as above.
Is a batch file that creates the structure of one or more PAC files by copying the software releases (that make up the PAC file) from the network to a folder on the local machine. Each folder corresponds to a PAC file. The builder then runs the Pack tool to create a PAC file from the contents of each folder. It is required to create more than one PAC file as one PAC file may not fit on one disc. It contains all items on Image BOM with IsSingleApplicationRecovery is TRUE.
Appinfo.ini: Contains all applications and drivers that go on the Foundation Image and are available for recovery through Chrysalis (Single Application Recovery).
12.2.1.5 Files required for BDVD
AllModules.TXT: Contains all modules and EPCs on a base unit.
12.2.1.6 Files required for Media Creation
perm modulues.cmd: Contains all permanent modules and EPCs for base unit (IsPermanent is TRUE).
temp modules.cmd: Contains all temporary modules and EPCs for base unit (IsPermanent is FALSE).
BaseUnitInfo.INI: Contains all base units for a project.
Build tools also check in software releases and images and thus need to be able to have a method of writing release data to the database.
Below is sequence of how VOA SW planning occurs currently:
In reference to
Many of the activities depicted in
Install Command Line: \\us-sd-itd-san-1\swlibrary\lsvrelease\0503904.SND\VIDP070503904.exe-*56GnArS40
Use Add/Remove programs.
New Version of VEC and fixed mread issue.
Changes from Previous:
Now referencing
Now referencing
With reference to
Defect Priority
Defect Severity
Defect Exposure
Defect Resolution by Application Champion
Defect Resolution by Module (First Level Applications on FI BOM Should be Included)
Ton Ten Deferred/Will Not Fix Defects
While the particular SYSTEM AND METHOD FOR SOFTWARE INTEGRATION AND FACTORY DEPLOYMENT is herein shown and described in detail, it is to be understood that the subject matter which is encompassed by the present invention is limited only by the claims.
This application claims priority from U.S. provisional application 60/722,130, filed Sep. 29, 2005, incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60722130 | Sep 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11541433 | Sep 2006 | US |
| Child | 13160715 | US |