15-413 Software Engineering
Fall 1998
Carnegie Mellon University
Pittsburgh, PA 15213
Version 0.1 9/14/98 Robin Loh. Created
Version 0.9 10/29/98 Dan McCarriar. First revision of integrated document.
Version 1.0 11/25/98 Dan McCarriar. More revision and integration.
Version 1.01 12/8/98 Dan McCarriar. Modifications to sections 2.0 and 3.1, expanded TOC, verified members list.
Preface:
This document addresses the requirements of the PAID system. The intended audience for this document is the designers and the clients of the project.
PAID Members:
Bernd Bruegge, Elizabeth Bigelow, Elaine Hyder, Robin Loh, Jack Moffett, Eric Stein, Keith Arner, Swati Gupta, Russell Heywood, Joyce Johnstone, Luis Alonso, Orly Canlas, David Garmire, Jonathan Hsieh, James Lampe, Yun-Ching Lee, Wing Ling Leung, Kent Ma, Georgios Markakis, Richard Markwart, Dan McCarriar, Reynald Ong, Adam Phelps, Arnaldo Piccinelli, Euijung Ra, Qiang Rao, William Ross, Pooja Saksena, Rudy Setiawan, Timothy Shirley, Michael Smith, Barrett Trask, Ivan Tumanov, Anthony Watkins, Jonathan Wildstrom, Brian Woo, Stephane Zermatten, Andrew Zimdars
Table of Contents:
3.1 Overview
3.2 Functional Requirements
3.3 Nonfunctional Requirements
3.3.1 User Interface and Human Factors
3.3.2 Documentation
3.3.3 Hardware Consideration
3.3.4 Performance Characteristics
3.3.5 Error Handling and Extreme Conditions
3.3.6 System Interfacing
3.3.7 Quality Issues
3.3.8 System Modifications
3.3.9 Physical Environment
3.3.10 Security Issues
3.3.11 Resource Issues
3.4 Constraints
The general goal of the PAID system is to provide a powerful, extensible architecture for fast and efficient information exchange. The system should be scalable to accommodate a network of 6000 clients internationally. The system should also function on several types of computing devices, such as desktop computers, laptop computers, and personal digital assistants (PDAs). The system should have the capability to take advantage of advances in computer hardware as well as improvements in network technology and bandwidth. The architecture of PAID should allow for the addition of new data and functionality without the need for a complete system redesign. To provide this extensibility, the PAID system is subdivided into the following subsystems, with their own individual goals:
Within Daimler-Benz, aftersales information is created and distributed by different departments. The major information sources today are service, parts, and vehicle information. Depending on the type of information, the company utilizes a variety of different distribution channels. Table 1 shows the main aftersales information types, the respective end user applications and distribution channels.
| Information Type | Application | Distribution Channel |
|---|---|---|
| Service Information | WIS | CD-ROM, Paper, Microfiche |
| Diagnosis Information | STAR DIAGNOSIS | CD-ROM, Paper, Microfiche |
| Parts Information | EPC | CD-ROM, Paper, Microfiche |
| Vehicle Information | FDOK | CD-ROM |
| On-line Car Configuration Data | MBKS | CD-ROM |
| Work Units and Operation Texts | ASRA | CD-ROM |
| Damage Codes | VEGA | On-line |
Table 1. Main aftersales information types, applications, and distribution channels
These distribution channels are typically very reliable but also very slow and inefficient. For instance, the distribution of service, parts, and vehicle information to the worldwide Mercedes-Benz sales organization is done monthly via a set of 12 CD-ROMs. This information is already partially outdated when it gets to the dealer. Looking at the information distribution channels that are available today through network technology, we can see that the current method of information distribution is too slow and inflexible to meet the demanding business requirements of Daimler-Benz.
Integration of different information types is also an important issue. As shown in Table 1, there are currently seven disparate information applications that dealers must consult. Additionally, many dealers also have their own internal information system that stores data of interest to the dealer, such as customer information and inventory. Because data for the Daimler-Benz information systems are only updated monthly, important interim bulletins and updates are often distributed via paper, forcing the dealer to consult multiple sources for the most recent information. The variety of systems currently used also results in instances of double or triple data entry.
Daimler-Benz is constantly extending its business in terms of new product lines and new models of existing product lines. The amount of aftersales information is increasing due to the introduction of these new products. With the introduction of new aftersales information systems, additional information distribution channels are created, which will lead to a proliferation of distribution channels. This makes the information management process (creation, publishing, distribution, installation), from a technology and management point of view, very complex and expensive.
In summary, a reliable, flexible, and scalable solution for active information distribution is needed. In the next section, we will present our proposal for a new information distribution architecture that will not only improve current information distribution processes, but that will also be extensible and flexible enough to allow for the addition of new types of aftersales information.
The PAID system will be composed of five individual subsystems, each having their own set of requirements:
The Network subsystem will provide a method of communication between a dealer and the central database, as well as provide communication between the other individual PAID subsystems. Specifically, the Network subsystem will allow a remote user to request information from the central database, and to receive updated information from the central database.
The Authentication subsystem will provide secure access to PAID. There are two major categories of users, the administrators and the general users. The general users will be able to install the PAID system, log in when they need to use it, make query requests, see their user profile, and logout. In addition to these actions, administrators will also be able to make changes to the database, control user access, modify user profiles, and add and delete users. The general user type can be subdivided into Daimler-Benz affiliated users and nonaffiliated users. Authorization to the system is available in two methods. For simple access of data stored on local PAID systems in a dealership, the users will have to provide a name and password. For accessing data stored on the Daimler-Benz servers, a SmartCard will be used to authenticate the individual users. Authentication will handle large groups of users, providing easy access to extend the system to new dealers or other affiliates. Authentication on the local machine will be fast, and will not affect the performance of the system.
The User Interface subsystem will provide end users with an easy to use graphical interface to the data accessed through PAID.
The Learning subsystem will watch for "triggers" (data transactions) from the main database. The system will selectively analyze, using off-the-shelf data mining software, this data and determine a more intelligent, streamlined, and efficient way to handle future data transactions.
The Database subsystem will engineer a way for aftersales data to be stored and replicated in an efficient manner on the PAID system computers. These computers include the main database servers maintained by Daimler-Benz headquarters, the individual dealer servers, and the dealer clients. Another requirement for the Database subsystem is to provide for the storage of persistent data for other PAID subsystems, and the uploading of sales, marketing, customer and vehicle information to the main Daimler-Benz servers.
The Network subsystem will implement both pull and push functionality. Pull functionality will allow a dealer on a remote machine to request the transfer of data from the central database. Push functionality will allow the central database to send updated information to a dealer. Also, the subsystem will allow updates to be multicast to multiple dealers. Transparent to the functionality described above, the Network subsystem will provide on-the-fly compression, using a scheme such as adaptive compression, to reduce network load. Error checking will also be incorporated to ensure that data passed over the network is not corrupted. Finally, the Network subsystem will monitor server load and network response to assure that information is routed in the most effective way possible. To implement these requirements, the Network team will investigate third-party solutions such as Marimba/Castanet to handle push/pull communication modes and implement such features as multicasting.
The User Interface subsystem will provide a user-friendly interface for end users to interact with PAID. The User Interface subsystem will also be responsible for displaying data in a useful manner to end users. To accomplish this, User Interface will also handle the processing and requesting of data. The User Interface subsystem will help the user work efficiently in disconnected mode, using only a local database, as well as in connected mode, obtaining information from the main Daimler-Benz database. It will also enable the user to switch between these two modes. Furthermore, each user may have his/her own preference settings for the system. The User Interface subsystem will provide the interface to the database subsystem to store and retrieve these preferences. Another option will be the storage of individual preferences on the SmartCards used for authentication.
The functional requirements of the Authentication subsystem are to provide secure access to PAID and all the data contained within. To receive access, a user will be required to authenticate themselves using a user name and password. If they wish to view data not contained locally, the user will have to insert their SmartCard into the attached reader. The SmartCard will contain the user's authentication information, which will be used to log the user into the remote databases. Whether or not a user has access to the information they have requested will be determined by the database based on a user model provided by the Authentication group.
The Database subsystem has several functional requirements, including:
The Learning subsystem will analyze behaviors and suggest actions to implement. It will do this by monitoring the behavior noted by the database and responding to database triggers. Specifically, it will store frequently accessed records in the local database and reschedule updates over the network to avoid congestion and periods of high network load. Responses to triggers from the database need to be at least semi intelligent, with a lower bound on unreasonable or erroneous prompts. Depending on the user's specification of a cost/speed balance, the learning system should recommend only behaviors that will enhance the cost/speed performance of the system. The system should also be user friendly, in that it should never completely take control of the system from the user. This can be accomplished using preference settings on the client machines. Finally, the decision making process should be done in a reasonably short period of time.
PAID will be used for different tasks by a wide range of users with different needs:
All users will considered computer novices, making extensive online help an important requirement. It will also be important for the system to be user friendly. The system will have to offer appropriate access to data for each type of user, paying attention to ease of use as well as the security of sensitive information. PAID should always let the user know whether he or she is accessing information from a local or a remote database. Also, when repeated access of the same data is detected, the system should notify the end user and guide him or her through the process of copying the data into the local database. Since the system will be used worldwide, it is important to be able to accommodate different languages and cultures.
PAID should be useable on the following platforms:
The interface should be consistent across platforms. Someone normally using the system on a handheld computer should not be confused or misled by the PAID user interface on a desktop PC. Every application should have the same look and feel.
For authentication, the SmartCard is being implemented as a security mechanism because it can provide a higher level of secure transactions than a regular user/password combination. The card allows for the storage of a larger key, which will act as a password. The larger key increases the level of difficulty and time required to break into the system. By requiring the user to have the card when accessing remote data, we are providing increased control over access to data stored on the main Daimler-Benz servers.
There are three ways the user will interact with the Learning subsystem. First, the subsystem will have a learning preferences panel on the client machine. This panel allows the user to decide how much control they wish to give to the system, or how frequently they wish to be prompted for updates or changes. Second, the server can access reports of the network activity that the learning subsystem monitors through the server-side user interface. In general, these two interfaces may be more advanced features of the entire user interface, but detailed documentation should help expedite the learning process. Finally, when the user wishes to download large files but not keep their connection open long enough to finish the download, the subsystem will let the user know of the problem. In the form of a button panel, it will inform the user of the estimated download time and give the user the opportunity to refine their request or cancel it.
Documentation will have to be included in the form of an extensive online help system, multimedia or paper tutorials and reference manuals for each type of user. The general user interface as well as the most common tasks performed should be described in a comprehensive step-by-step method. All project documents should be published in HTML or Adobe PDF.
Documentation describing the user model and security rights will be provided to the administrators of the PAID system. In addition, the administrators will receive a list of security limitations known to the developers as well as the methods employed to prevent complete loss of security in case of a successful attack. A description of login, logout, and query procedures in addition to a manual on the use of the Java card will be provided to all users. PAID software documentation must be provided in JavaDoc and include UML models.
Documentation from the Learning system will include an explanation of both the learning preferences panel on the client side and the network activity reports on the server side. It will describe the functionality of each learning preferences panel option. Also, it will include an interpretation of the statistics generated by the network activity reports for the server interface.
PAID will run on two different user hardware platforms: a desktop PC and handheld computer (including laptop computers). The desktop PC must be powerful enough to run a Java virtual machine at a satisfactory speed and have good display capabilities. Hard drive storage will not be required, except for storing the program itself, but the system will be able to make use of a large storage capacity by creating and caching a local database. The desktop PC should have a connection either to the public Internet or the Daimler-Benz network. The handheld computer will need to be able to run Java and have enough storage space to hold both the program and the data that will be used while disconnected from the desktop PC or the network. It should be able to connect to a desktop PC.
The type of connection used (Modem, Ethernet, ATM, ISDN, etc.) will have an affect on the operation of the Network subsytem, in that it will attempt to determine the speed of the connection, and adjust the network parameters (such as TCP/IP window size and compression methods) in order to make full use of the connection speed and to minimize congestion.
For authentication, a Java card reader compatible with the PAID system (e.g. Cyberflex 2.0 Multi 8K) is required on every system PAID will be run on.
There are separate sets of hardware considerations for the dealer and Daimler-Benz servers. These servers, which will hold the bulk of the aftersales database, need to be powerful and scalable in order to supply the necessarily fast query times now, and in the future, because the aftersales database will keep growing. Since the Learning subsystem will need to analyze data transactions from as many as 6000 dealers, considerable RAM will be needed on the Daimler-Benz servers to carry out the complex calculations.
PAID should be able to download and display a large amount of data at a satisfactory speed on a dial-up connection (56k modem/ISDN). Slow network performance or insufficient storage space should be diagnosed by the system and explained to the user via a graphical interface.
Login and logout should take no more than 2 seconds. Remote connections to the PAID system should be handled as quickly, assuming there is no discernible lag in the network connection. These approximations are dependent on the standards of the intranet and extranet and may be adjusted as more information is obtained.
When transmitting data across public networks and some private networks, encryption will be employed to protect the data from theft. It will require time to encrypt on the server side and decrypt on the client side. This will only happen during transmissions over open networks. Once the data has been received on the local machine, it remains unencrypted to ensure fast access to stored information.
For the Database subsystem, queries to fetch data from the aftersales database need to be very fast, typically under 20 seconds. The Database subsystem relies on the Network and other subsystems for communication with other system objects. This may result in bottlenecks for the Database subsystem. These bottlenecks will be dealt with by the other subsystem groups. Generally speaking, the sum total of all the performance constraints of all the PAID subsystems for a particular task should be "reasonable".
The Learning subsystem will perform off-line data analysis, which will be the most time consuming process. Nonetheless, the decision making process should be relatively fast if optimal algorithms are implemented. The actions that the decision making process recommends, however, should speed up the information transaction process for the different scenarios. However, if the user's available memory or connection speed limits their downloading capabilities, the subsystem will either prompt the user to refine their request or automatically prioritize the download.
The Network subsystem is expected to transmit at the highest speed allowable based on the connection between a remote machine and the central database. In addition, the Network subsystem may make use of compression techniques in order to maximize throughput. The estimated ratio of server to clients will be 1:150. In the event of a network overload, the network will use shared throughput and attempt to circumvent bottlenecks by transmitting packets along an alternate route. Response time will be dependent on how quickly congestion is discovered.
Errors such as data inconsistency or any extreme or unusual condition (e.g. network congestion, server unavailable or unreachable) should be detected by PAID and displayed to the user. The system should always display clear error messages and be able to make suggestions to the user as to what measures should be taken in order to fix the problem. Specific notifications that the PAID system must provide to users and administrators are as follows:
Unauthorized Access: If a user requests information to which they do not have access rights, they should be notified.
Corrupted Key: Access to PAID will be denied until a correct key is provided. If one is not provided after 3 tries and the user is attempting to log into the system over a network connection, Daimler-Benz administrators will be notified that someone is using a bad key and from what IP address the request is originating.
Idle Timeout: If there is no activity for a period of time specified in each user's profile, the session must be terminated and the user notified of the termination.
Download Time: To minimize the cases where the user cannot finish their download before they disconnect, PAID will inform them of the estimated download time. If the user disconnects before the download is complete, the subsystem must forget the download.
Other extreme conditions should be handled as follows:
Lost or Destroyed SmartCard: Without a card, the user will be unable to access any information stored on the Daimler-Benz servers. Users will be required to contact Daimler-Benz immediately to obtain a new card containing a new key.
Unexpected Shutdown: In the case of an unexpected shutdown of PAID, the system must clear the cache. If a remote session was open, it will be terminated on the remote end after a time-out. On the local side, we have to ensure that the cache is cleared and the database remains secure.
The major sections of the Database subsystem are persistent storage (event logs and behavior files), the data analysis functions, and the connection to the database/event service. In the situation that Database is unable to reach persistent data, the subsystem is crippled. In the event that the subsystem receives too many triggers/events to process, it will fall back to a less intelligent yet fast algorithm (logging, and a default response) to process requests. The excess events will be handled later by the data analysis cycles. In the event that the data analysis process incorrectly recommends actions, the learning preferences panel on the client side will have an option to reevaluate the recommended behaviors.
In the case of database failure, disk failure or other types of errors associated with a compromise in database integrity, a recovery mechanism will be supplied to correct the error. Data will be analyzed for integrity and the parts whose integrity have been compromised will be removed. After this, an update either from the servers or from the CD or other read-only media will be performed to restore the missing data.
If there is not enough storage space for the database, the Database subsystem will return an appropriate error code to the PAID subsystem that requested the data in order to invoke a user-cleanup of the storage device either by removing parts of the database which are no longer needed, or by removing other files.
If a connection cannot be established as signaled by an error code from the Networking subsystem, then the database subsystem will try to find the data in the cache or on the local store, and if it is not found there, it will return the appropriate error code to the PAID subsystem that requested the data.
If the data passed in by other PAID subsystems has incorrect format or is not expected, then the Database subsystem will return the appropriate error code to signal the situation and abort the transaction.
If requested data does not exist on the local store, then there are several actions that could be taken in order to download the data. The data can be retrieved from a server, or it can be retrieved from a base set of data found on CD or other storage mechanism.
In the case that the database has not been installed, the Database subsystem will return the appropriate error code to signal the User Interface subsystem or other subsystems to prompt the user to install the database.
There are three exceptional situations that the Network subsystem may encounter. The first situation is network problems. In the case that the network becomes unreliable, any ongoing transmissions will be terminated, and both ends (the remote machine and the central database) will be informed of the interruption as well as the state of the transmission upon termination. The second possible situation is that the dealer (on a remote machine) may choose to terminate a transmission, in which case the central database will be informed of the situation and both ends will be informed of the state of the transmission at the time of termination. The third possibility is that the local program is terminated unexpectedly in the middle of a transfer (e.g. in case of power failure). In this case, the client would clear recieved information from its cache upon reboot and continue as if the transfer never occured.
The Network subsystem functions as the lowest layer or core of PAID. All messages sent over the network will be passed through this subsystem. The network subsystem looks at the client and server side as black boxes, meaning it does not recognize or account for any explicit interactions with other subsystems. All interfacing to this subsystem will be done through the Network API (NAPI). However, there are two main subsystems that we expect to interface with NAPI in order to provide the basic functionality of PAID. We anticipate the Learning subsystem will pass data for automatic server to client updates through the network, in the form of either a point to point or multicast message. We also expect the Database subsystem to request and receive desired information from the server through the network subsystem. All interactions between these subsystems will take place on the CORBA bus through a Java interface.
The User Interface subsystem primarily communicates with user input devices such as a keyboard, mouse, and possibly a touch screen. Here, a method of counting the number of mouse clicks may need to be implemented in case the end user pays per mouse click rather than a flat rate for information requests. Data will be displayed or printed, and sound may be used to alert the user. The system should be able to display information clearly, even on small screens, and, in the case of the handheld computers, be easy to read outside or in unusual environments.
The Authentication system communicates with the User Interface subsystem for the most part in the following situations:
Login: The user interface subsystem notifies the authentication subsystem, which in turn verifies the user through their user name and password. The login request is forwarded on to the local PAID database, which will attempt to log the user in. The database subsystem verifies the user and starts the session if the user has access.
Query: The user interface forwards a query to the authentication subsystem. The authentication subsystem adds the necessary security information before passing the complete query to the database. The results of the query are passed backed to the user interface for display. If the request requires data from the Daimler-Benz servers, then the user is required to insert their SmartCard.
Logout: The user requests a logout through the user interface. Authentication informs all the subsystems of the request and asks them to close all the current user sessions. During this time, any data cached locally and not stored in the local database must be removed. When all subsystems have reported logout complete, the user is notified of the successful logout.
Authentication is going to be transparent to other PAID subsystems, meaning that other subsystems will not be aware of the existence of Authentication. This also means user interface does not change the behavior of the Authentication subsystem.
The Database subsystem receives most data from three sources. First of all, it can retrieve data from the local store that has been put there earlier. Second, it can access a CD in order to retrieve a portion of the base set of data, or data from an update CD. Third, it can receive data from another PAID subsystem, such as Network, if the data is in transit from a server or to a client; or from some other PAID subsystem which is submitting either persistent data to be stored, aftersales data that needs to be propagated up to the servers, or a request for some data to be retrieved.
The Database subsystem outputs either to a PAID subsystem or to the local store. When the Database subsystem is manipulating the local store, it can either be manipulating a local database which contains aftersales data, a local store area which contains persistent data from the other PAID subsystems, or an area designated as a cache. The Database subsystem also outputs data to PAID subsystems that request it, and also to the Network subsystem in order to send data to servers.
The Learning subsystem interacts only with the database/event service subsystem. It receives input of database events from the database and outputs recommended actions to the database. Additionally, the Learning subsystem is the only subsystem using its data, so we can safely choose any desired data format. We assume that the database will allow as much granularity as possible, so that we may break downloads into individual files.
The Network subsystem must provide fast, portable, and reliable information transport over the network for PAID. In order to maximize speed efficiency, the network subsystem will provide compression on the fly, be selective (multicast or point to point) about the amount of information transported, and optimize routing of the information. To ensure portability, the subsystem will be written using 100% pure Java. This means any hardware/operating system which has a Java virtual machine will be able to route information through PAID over the network. Reliability is guaranteed as the subsystem follows the ISO Open System Interconnect (OSI) model.
The User Interface absolutely must be reliable and trustworthy, even across different languages, because dealers may be charged according to the usage of the system. The user interface must also be portable across different platforms and input/output devices.
The Authentication subsystem will ensure that no data is given to unauthorized parties. Measures will be put into place to prevent a successful attack on the PAID system from being too damaging. While some data may be compromised in such an attack, the rest will continue to be protected. As with the rest of PAID, authentication should be platform independent. At no time will PAID be operational if authentication is not functioning.
The Database subsystem must provide reliable storage for aftersales data and persistent data from PAID subsystems. It must guarantee that erroneous data is not passed to PAID subsystems for display to the user. It must guarantee that all errors which occur in the Database subsystem are either handled adequately by itself, or adequately trapped and passed to the PAID system that initiated the transaction. It must guarantee that if a data transaction is interrupted halfway, that the database or local store state is not corrupted or otherwise altered in other words, it must provide transaction based data storage. In the extreme case that data cannot be stored on the local storage mechanism, the Database subsystem must still provide access to aftersales data and upload capabilities by interfacing directly with a server through the Network subsystem.
Fundamentally, the Learning subsystem will attempt to recommend near optimal actions. For it to be reliable, data transactions will need to be substantially more streamlined and efficient for each of the applicable scenarios. The system needs to realize when it is making erroneous recommendations and correct the process, either by user input or a system checking process. In cases where the network goes down or there are database malfunctions rendering the system unable to access new data, the system will recognize this and not act until connections are restored. Due to the fact that the data analysis process restarts at arbitrary time intervals, if the subsystem itself were to crash it will easily resume operations once restarted. Data files will be continually saved to ensure this.
As more dealers are added to the system, scalability issues might have to be considered if the Network subsystem's response is affected by an overload of responses to the server.
Input/output devices will likely be improved in the future, and new types of devices may become available. New languages will be added as countries develop and as Daimler-Benz expands. PAID will need to keep up with these changes in order to remain useful. The user interface itself (as well as online help/tutorials) will likely be improved according to user feedback. Perhaps in the future, the capabilities of the system will need to change, and the user interface will also have to accommodate these changes.
The Authentication subsystem will allow modifications to the user and access rights models by administrators. In addition, the technologies used for authentication may change.
The Database subsystem is free to be changed as long as its behavior stays the same and it still conforms to the specified APIs. The nature of the aftersales database could change in the future. It may become an object oriented database, or undergo serious modifications to the database structures because of performance requirements or the need to store additional data. The Database subsystem must develop a set of APIs which allow it to incorporate all these changes transparently to the other PAID subsystems.
Within the Learning subsystem, the data analysis process is a good candidate for future modifications. If the subsystem relies on one major data mining algorithm to analyze data, multiple, more optimal data mining algorithms for specific scenarios may be added. The object oriented system will be easily extensible to accommodate such modifications.
The User Interface must be easily usable in a large variety of environments. The desktop PC version will be used in offices that are well lit and comfortable for the user. The portable version will have to remain usable in much more difficult environments: garages, any site away from the dealership where a car has to be repaired (e.g. a customer's garage, or roadside). It will have to survive dirt and shock. The environment may be very noisy. To be used in such extreme conditions, the user interface of the portable version will need to be particularly clear and user-friendly. Moreover, unforeseen events may prevent the user from seeing or hearing a specific signal from the computer. Important information should be conveyed using several kinds of signals (e.g. a visual requester and a sound to signal an error). The emphasis should be on displaying as much useful information as possible while remaining easily readable.
The physical environment that the Authentication subsystem is concerned with is highly dependent on the SmartCard reader and the SmartCards themselves. Authentication will not work if the card reader is inoperable, the card is damaged, or the card reader can not read the security information. Also, care must be taken when dealing with the SmartCards since they are sensitive to environmental conditions.
All access to data will be controlled at the user level. A mechanic will have access to those things deemed necessary for a mechanic to access, and the same for other users. Furthermore, there should be at least two levels of security for every user: one for accessing the local database and another to access remote Daimler-Benz databases.
There should be a minimal number of people who can edit things in the system. Only administrative users will be able to change user profiles or user access rights. Every data access will be verified to ensure that a user has the right to access the data requested. The access rights data structure will most likely be some form of Access Control List, which for each object, a list of authorized users are listed.
In building the security model, certain types of attacks are being considered. Authentication is concerned with protecting the system from persons pretending to be dealers and from people attempting to listen to network communications in order to capture data transmitted from server to client. Additionally, we are concerned with unauthorized users attempting to gain access by imitating the Java commands internal to the PAID system. Finally, while the physical dealer machines can not be protected by any software methods, measures will be in place to make accessing the data stored locally as difficult as possible.
Data which is located on the CD, local store and the local aftersales database must be secured with an access password and possibly encrypted in order to allow data security and integrity and access only through the Authentication subsystem.
Each piece of data in the database will belong to a group. In order to access any one of these groups through a query, a PAID subsystem must present a user key which can be passed to the Authentication subsystem along with the data group designation and verified for valid access.
The Database subsystem will store the user database for the Authentication subsystem and will accept queries from that subsystem to retrieve appropriate user data as well as to check pieces of data such as passwords or authentication credentials found on a SmartCard.
In order to guarantee the integrity and security of the data, other PAID subsystems will not be allowed to run direct SQL or other queries on any piece of data stored by the Database subsystem. Only the Database subsystem will have access to the data, and will verify all requests for data with the Authentication team, and only allow access to data clearly designated as accessible through the Database subsystem API.
The main resource requirement for most subsystems will be installation, which will be performed by a system administrator in most cases. Administrative users are also responsible for handling user accounts, as well as adding, deleting and modifying user access rights.
Ideally, the local storage on the system running the Database subsystem, including the local store and the local aftersales database, should be backed up regularly in accordance with policies set up by the administrators of that system. Ideally this would happen on a regular daily-weekly-monthly rotation with any mechanism which can accommodate the size of the data which has to be backed up.
PAID will be developed using Java (JDK v1.1) in conjunction with JDBC for database access. Object and CASE models will be created using Together/J. Source code control will be handled using CVS. The Schlumberger Java Card will be used as a method of authentication.
If any subsystems use third party software packages not implemented in Java, those packages must be wrapped in Java.
Section 3.5 will be included in a future revision of this document.