Examples of RAD from JAMES
1.0 General Goals - Bonus Subsystem
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.
3.3.4 Performance Characteristics - Bonus Subsystem
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
