The bonus system is a way for a Mercedes owner that also owns a Smart Card to receive benefits for using Mercedes dealers for their
service needs. Whenever maintenance is performed on the owner's Mercedes, they will earn a certain number of bonus points based on
the type of service. These bonus points can be redeemed for other services or products.
2.0 Current System - Vehicle Subsystem
The current simulators from Daimler-Benz consist of a Windows SA/RT simulator written in C, that simulates only the vehicle seat. There
is also the AIM/CANalyzer simulator software written in a Canalyzer language similar to C, from Daimler-Benz that can simulate multiple
vehicle functions running on a laptop computer.
3.0 Proposed System - VIP Subsystem
3.1 Overview
The VIP subsystem will be designed to provide personalization functionality of the JAMES system. Essentially, the VIP system is intended
to maintain a record of the user's personalized preferences and data which may be applied or accessed in any JAMES enhanced vehicle.
The settings that the users can manipulate fit into two categories. First, the user can adjust settings on physical devices within the car such
as seat position, mirror position, radio channel presets, dashboard light intensity, fuel economy, and climate control. The second group of
settings are those which do not have a real-world component. This group will include the database portions of the currently implemented
phone book, address book, and related applications as well as extensions to other configurable objects. The VIP system behavior will be
almost entirely automatic, leaving its activity transparent to the user. This will lend a continuity to the feel of user's driving experience across
all JAMES enhanced vehicles.
3.2 Functional Requirements
The functional requirements of the VIP Subsystem system are to store and retrieve data in an efficient, and flexible manner. In order to
accomplish this, the VIP system, upon insertion of the JavaCard, will query the vehicle to get a list of objects installed on the system. Once
this list of objects, everything from radio presets to seat position, is returned, the VIP system will attempt to find the best match
between what settings are currently saved, and what settings the car requires. After the user has restored his old settings, and makes any
new adjustments, the saving of settings will be done without any knowledge by the user. If the user wants to manually save and restore his
settings, he will be able.
3.3 Non-Functional Requirements
3.3.1 User Interface and Human Factors - Maintenance Subsystem
This system will be used by two main groups of people: First it can be used by an authorized representative of the owner of the car which
could be the driver, friend of the driver, fleet manager or someone else. Second, it can be used by the mechanic or some other
representative of the garage, such as a manager. The complete user definitions are described in section 3.5.2.1 User Model.
For simplicity, in the rest of this document driver will refer to the driver or any authorized representative of the driver, while mechanic will
refer to any authorized representative of the garage.
The central database, as used in this document is physically several databases, including several legacy servers. These servers will be
distributed across separate sites on the Inter/IntraNet. It will be used for long term storage of the maintenance history and possibly other
information. See the System Design Document for additional information on databases.
The assistant will exist on several different locations. There will be a home assistant for the owner to use at home, an assistant on the
vehicle for the driver to use, as well as an assistant in the dealer's garage for him to use. For the owner/driver, the assistant should be
simple and easy-to-learn. This is especially important for the home assistant, as users will have only occasional interaction with them. The
mechanic will have more frequent interaction with the assistant, so the interface in the dealer garage should enable mechanics to enter
transactions quickly and easily. In both cases, users should be protected from making significant errors, as these records are maintained
for the life of the car.
In terms of hardware, the driver will need a computer and a card reader in his home to download the maintenance applet and view the
maintenance history. Software will be needed to interface with the card reader. The mechanic will also need a similar computer and card
reader in the garage. In the vehicle, the maintenance system expects access to a touch-sensitive screen that can display our assistant and
receive input from the driver.
A final design goal for the user interface is to achieve the same elegant simplicity of interaction for which Mercedes-Benz vehicles are
known. The interface should not appear complicated, nor require extensive explanation.
3.3.2 Documentation - Travel Subsystem
Documentation should be included which covers all use cases of the travel application. Within it, there shall be sections covering the user
interface and how it is to be utilized in conjunction with the rest of the travel application in order to provide all the functionality covered in
the problem statement. Documentation will be available on how to plan a route, update the SmartCard, edit a route and view the route.
Documentation will account for different environment settings where the system is used, such as planning the trip on the user's home pc, or
viewing a route on the road. The target audience of the documentation are the users of a Mercedes vehicle. The documentation will take
into consideration that both drivers and passengers could be using the system while on or off the road.
3.3.3 Hardware Consideration - Logbook Subsystem
The LogBook application will have pieces running on three different hardware platforms: the car's computer, the SmartCard, and the
user's computer. The logging of trips will be done on the car's on-board computer, and the tax forms will be printed on the user's
computer or prepared by a service center. The only thing left for the SmartCard to do is transfer trips between the user's computer and
the car.
The car's computer is comparable to a desktop personal computer, probably with a real-time operating system, and should be capable
of running full Java. Also, the storage capacity should be much greater than what the SmartCard has, however space will still be a
consideration in this application.
The SmartCard itself runs a watered down version of java with no threads, no garbage collection, no exceptions, or much of anything
that makes Java useful. The card has a total of 2.8KB of space available for our program and any data we need to store. The other risk
with the card is that the Java operand stack only has 32 bytes. So, you can't have a deep call tree, use class hierarchy, or have lots of
local variables. The code that goes on the card has to be without excess. Making a good, reusable, application to run on the card will not
be easy.
The user's computer, which handles the tax forms and final storage of trips, should present many design challenges. Talking to the card
maybe somewhat difficult, as it is necessary to go through an old DLL, but any ugliness there can be encapsulated. Once the
communication is taken care of the tax form generator shouldn't in any way stress the resources of a modern desktop computer.
The web interface used by the driver should be relatively fast over a 14.4 Kbps modem connection. A page should take no longer than 10
seconds to load at this speed. The web page therefore can not hold more than 30 KB of information. This includes the information
transferred to the user as well as information obtained from databases through queries. The system should be able to sustain this rate with
a moderate load of users.
The dealer terminal should have a user interface with no noticeable delays. Any delay in the system should be accompanied by a status
message or at least an indicator that the slowdown is a result of information retrieval and not poor programming. The dealer should be able
to download any needed information and present it to the customer within 10 seconds, barring hardware or network problems.
The Smart Card can only hold 2.8 KB of data. Anything placed on the card must be smaller than that. Information traveling over the
network should be as small as possible to eliminate delays. The servers holding the information should have large enough storage to
accommodate the data with at least 15% breathing room and redundancy, if cost effective. The servers holding the information should be
expandable so in storage need increases, more space can be added.
3.3.5 Error Handling and Extreme Conditions - Logbook Subsystem
3.3.5.1 Error Handling
There are three components to the LogBook Assistant software: the on-board computer code, the personal computer code, and
SmartCard transfer code. These are subject to various types of input errors, to be discussed separately. The onboard computer code
communicates with the user (during driving) via three buttons: "Start Trip," "Pause Trip" and "End Trip." In each state (in a trip, or not in a
trip) the behavior of these is well-defined: pressing "Start Trip" when a trip is in progress shall start a new trip, pressing "Pause Trip" when
a trip is in progress shall suspend or resume the trip (as appropriate), and do nothing if no trip is in progress, and pressing "End Trip" when
no trip is in progress shall be ignored. The onboard computer code communicates with the administrator (or the server, when retrieving
trip information) via the onboard touch screen. The data retrieval mode (copying information onto the card) will be designed to eliminate,
as much as possible, any opportunities to make invalid input: trips or legs which may be retrieved or deleted are displayed in a list box,
and no buttons may be pressed for invalid operations (e.g., if the user does not have permission to delete a trip's information, the 'delete'
button shall be either disabled or hidden). The personal computer component of the system has the most complicated user interface, since
t must allow the user to select trips for which to print tax deduction forms and possibly to edit trip data (join or split trips). Until the
functionality of this component is determined, input errors and their handling cannot be fully analyzed.
3.3.5.2 Exceptional Conditions
'Exceptional conditions' in the context of the LogBook assistant are assumed to be limited to starting or stopping a trip very shortly
after starting the car or very shortly before stopping the car (i.e., turning the motor on or off). In these cases, the trip's data is 'rounded off'
to reflect he car's location when the engine starts or stops, rather than when the 'Start Trip,' 'Pause Trip' or 'End Trip' buttons are pressed.
The conditions for performing such round-off are not yet defined, but a suggested possibility is that the odometer has not changed by more
than 0.1 miles. It has also been suggested that this be possible to change after manufacture -- perhaps by taking the car into a service
center to change the onboard computer settings.
3.3.6 System Interfacing - Maintenance Subsystem
This system is primarily standalone. It interfaces with the authentication subsystem to authenticate the driver and dealer. There is a Bonus
Points system to reward the driver for maintenance requests. This will be implemented in the future. See the System Design Document for
further information. There will be an Event Notification System and a Name Service that will allow the Maintenance Assistant to
communicate with its user interface. It will also allow it to communicate with any other Assistant or system that uses the Event Notification
and Name Service. They will communicate using standard Java and CORBA. CORBA was decided over RMI because it allows the
system to talk to other systems there are not necessarily written in Java.
3.3.7 Quality Issues - Travel Subsystem
The system must be reliable, in the sense that it must provide the correct route information to the user. This means that the route and sites
of interest are displayed correctly. The system response time for a user request, such as View Trip, should take a maximum of 5 seconds.
The user must be notified if the current GPS location does not lie along the planned trip. The system must also be compatible with the
Schlumberger standards so that it does not damage the SmartCard in any way.
The system must recognize when certain components that it relies on are down. For example, if the GPS is not responding, the system
must deal with the problem appropriately.
The system must be aware of how much space there is left on the card. It should notify the user when there no more trips could be stored
on the card. Although, right now, the card may only allow one assistant at a time, it is expected to increase in memory and become a Multi
Functional Card ( MFC ). This means that the card will allow to have different assistants running at the same time, as well as allow
dynamic downloading of assistants. The Travel Subsystem should recognize that there are other applications running on the card. It should
never interfere with the other applications.
The component of the system which plans the route must be able to run on any hardware/operating system environment which has a Java
Virtual Machine. It is important not to restrict the user's choice on where they can plan their trip. The component of the system which
contains the specific trip information must be compatible with the Cyberflex SmartCard architecture. The cardlet should never perform
actions which will damage the Java Virtual Machine on the SmartCard.
3.3.8 System Modifications - Vehicle Subsystem
Initially the only component that will be simulated will be the seat. It will be simulated first through a Java stub and then through the
AIM/Canalyzer or SA/rt. If time permits this would be expanded to other vehicle components. The implementation side of the vehicle
bridge is likely to get changed as new seat, mirror, entertainment, etc. units are introduced. This may involve simply new CAN bus ID's, or
entirely new transactions on the bus. New units may also require modifications to the server side, for example if there are new parameters
that must be set or read from the unit. These are not as likely as modifications to the implementation side.
3.3.9 Physical Environment - VIP Subsystem
At this time, the target equipment is the Cyberflex JavaCard. However, the design of this system should be generic enough to take on new
features of cars, as well as new types of cards. For example, if there is more room on a new JavaCard, then there should be more data
stored.
3.3.10 Security Issues - Bonus Subsystem
Access to data must be controlled. No driver may alter any bonus point data. Mercedes policy makers shall dictate bonus points earned
for service and bonus points cost for service or product. This information will then be given to the system administrator of the web server,
who will change the information. The only information dealers may change are the bonus points on a Smart Card, and only after the driver
has a service done or purchases a service or product using their bonus points.
Physical security is also an issue. Any employee at a dealership should not be able to view all the information about a customer. Access to
the web server must be restricted to the system administrator only.
3.3.11 Resource Issues - Logbook Subsystem
The resources in the LogBook use the card as a data transfer medium and will be backed up on the external system whenever the card
is inserted to the card reader attached thereof. The LogBook system will be installed along with the rest of the JAMES system, most
likely at the factory with the rest of the car. The administrator will be free to administrate the logs as they see fit. Data on the external
system will be considered to be the master data; if an administrator modifies data on the external system and the resulting data conflicts
with newly arrived data from the vehicle or car, the external system data will be used.
3.4 Constraints - Maintenance Subsystem
The system will be developed with Java (JDK 1.1.4) with CORBA using VisiBroker. Object and case models will
be constructed using the CASE tool Rational Rose 4.0. Source control will be handled using Perforce. See Section
9. Issues of the System Design Document for further discussion. There will be an interface to the legacy system,
depending on the access granted to us by Mercedes.
3.5.1 Scenarios - Travel Subsystem
A driver wants to plan a business trip. He calls up the travel application on his pc at home, and calls upon it to create
a route. The travel application calls upon the map service, which displays a map, including the sites of interest which
are along the way of his route to be planned. He selects a route, then saves this route on the card.
A driver who has saved a route on the card is driving along the route planned and wants to see how far he is along
on the trip. He goes to the travel application and selects view trip, which calls the navigation system to find the car's
current location, then the map service to get the map of the location, correlating that with the route that was planned,
showing the current location of the car on the map.
A driver decides that he doesn't have time to stop at all of the sites of interest along the way between the beginning
of his trip to the final destination. He calls upon the update trip part of the travel application, which calls the
navigation system to determine the current location of the car, and correlates the map service map with the route
planned on the card to show on the screen the current location of the car on the map. Then, he deletes the location
at which he is unable to stop at. If he wishes to add it again, or add another location, he calls upon update trip to
show his current location, then selects a location from the map provided by the map service to add a location to his
route.
3.5.2.2 Use Case - Vehicle Subsystem
NAVIGATIONAL TEXT FOR THE USE CASE BELOW -- The top level use case illustrates the relationship between the various subsystems and the vehicle. The vehicle
subsystem provides the other subsystems with interface services to the vehicle. In terms of the services it provides
to other subsystems, the vehicle subsystem is divided into four areas. They are services to Logbook for getting
odometer, clock, date, and location readings. Maintenance for diagnostic testing. Travel for getting GPS
information, and VIP subsystems for controlling and getting information about components of the vehicle.
TOP-LEVEL DESIGN USE CASE
3.5.3 Object Model - VIP Subsystem
3.5.3.1 Data Dictionary
Driver Info:
This will consist of a driver name and a password and is used for the purpose of authentication and driver identification.
Car Description:
This is the description of the Car that will include the model of the car and a list of installed components in the car.
Component Settings Data:
This data is what will be returned to the VIP system from the car and will describe the settings of a component.
Other Assistant HCI settings:
This data will be returned from HCI and will describe the current settings and layout for the user interface settings of another Assistant program.
Default Data:
This data will be some default setting for the both component settings and for the other Assistants HCI settings.
Messages:
These are simple event notification that tells one process that something has occurred that is of importance to it.
VIP Settings:
This is simply the data stores the current settings of the VIP User interface.
3.5.3.2 Class Diagrams
The most basic object that VIP can manipulate is the CarComponent module. A CarComponent is any piece of the
car that can have a setting. It can be hardware, such as a seat or a mirror, or it can be software, such as an
"interface setting" for HCI.
In order to store and retrieve these CarComponents, a list object must be maintained. The list object is simply a
container for the CarComponents. It allows one to add or remove CarComponents, as well as query for a certain
type of component.
Figure 3.5.3.2.1 Car Component Object
Three different list of object must be maintained. The CardList is the list of CarComponents which the JavaCard
currently knows about. The HardwareList is a list of CarComponents that the Vehicle currently has installed. The
SoftwareList is a list of settings for components that are do not map to any physical object.
Figure 3.5.3.2.2 Car Component List
3.5.4 Dynamic Models - Logbook Subsystem
3.5.4.1 Sequence Diagrams
Start Vehicle
Figure 3.6 The user is starting the vehicle.
3.5.5.1 Navigational Path for the Web Application - Bonus Subsystem
The customer at home will be access the bonus points system using a PC through the internet. The customer will
be able to view his or her points and looks through the Mercedes Benz catalog finding out if his or her points will be
sufficient to buy goods listed on the catalog.
Web Application Navigational Path
3.5.5.2 Screen Mockup - Maintenance Subsystem
Below is the application that a mechanic would interact with. The interface provides a way to view and edit
the maintenance history of the vehicle and view recommendation. The driver would use a similar interface at
home, except the option to generate a new maintenance entry would not be available.
Screen mockup of mechanic application
This page is hosted by the Chair for Applied Software Engineering of the Technische Universität München. Imprint (Impressum)
