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
