Data processing: vehicles – navigation – and relative location – Vehicle control – guidance – operation – or indication
Reexamination Certificate
1998-12-28
2001-05-22
Cuchlinski, Jr., William A. (Department: 3661)
Data processing: vehicles, navigation, and relative location
Vehicle control, guidance, operation, or indication
C701S029000, C701S034000, C701S035000, C701S036000, C123S357000, C123S501000, C717S152000, C707S793000, C705S002000, C709S203000
Reexamination Certificate
active
06236909
ABSTRACT:
DESCRIPTION OF THE RELATED ART
Historically, computer programs were constructed from lower level hardware and software services by tightly coupling these parts together into a single executable image. This approach produced a computing environment that was inflexible and very resistant to predictable modification and adaptation to changing requirements. Applications written to these environments were very difficult to adapt to other computing environments. There was little opportunity to reuse application software to solve the same problem on a different computing environment.
More recently, computing architectures have incorporated a component approach. In these computing architectures, the base platform is composed by lower level components in an architecturally consistent fashion. This approach yields a more modular approach to software platforms, which allow any component to be replaced by another component, which achieves the same task. What allows this exchangeability of components is the standardization of software interfaces. A component is built to support one or more interfaces and provides these services to the computing platform. Any other component, which also implements those interfaces, can be used as a replacement.
Several examples of component architectures appear in the current art. These examples include the ActiveX architecture produced by Microsoft and the JavaBeans component model for Java produced by Sun Microsystems.
Computers have been on board automobiles since the late 1970s. Today, a typical vehicle contains anywhere from 5 to 12 microprocessors, while luxury cars have as many as 50. These processors range from 8 bit microcontrollers to 32 bit general purpose processors. The software programs that control power-train, chassis, integrated-body, and entertainment functions can contain more than 500,000 lines of code. The operating systems, language, libraries and techniques to implement the plethora of programs are quite varied with few consistent design methodologies. Historically, very few of these systems have communicated with each other.
As the complexities of vehicle software evolve and semiconductor technology advances, the electronics and software becomes even more sophisticated. Modern vehicular electronics systems now include bus architectures that allow some inter-ECU (electronic control unit) communication. Tomorrow's vehicular computing environment will further extend this trend to allow ECUs to collaborate and participate in a large variety of applications. These applications, including off vehicle communications, will continue to evolve as wireless communications technology becomes more pervasive.
Software as an increasing cost component of the vehicle is symptomatic of this evolution. This trend is expected to accelerate, causing software to become a significant time-to-market inhibitor.
Personal Computer (PC) platforms have standard, predictable configurations of hardware and software services. This configuration includes: CPU, memory, keyboard, mouse, monitor, serial port, and a small number of standard bus architectures, which attach external devices to the computing platform on the PC.
Programs written for the Personal Computer assume that this standard configuration is available and frequently fail to function properly if this assumption is violated.
Automotive embedded computing differs from PC and other Pervasive Computing situations because an automobile is a federation of connected devices as opposed to a single fit for purpose device like a smart pager or cellular telephone, or a reliable configuration of devices as is defined by the defacto standard PC.
Applications need access to functionality conveyed by devices on the automobile, either to poll their current status, as in the case of a fuel gauge, or manipulate the device, as in the case of radio station presets on a radio application. Because the population of devices can vary by individual automobile based on dealer and aftermarket device add-ons, the applications cannot rely on a fixed, standard population of devices. As a result, applications need to be written in a manner that is independent of device implementation and device configuration. When applications are written to standard APIs, independent of implementation details, they are more portable across car models and option/aftermarket add-on device populations. In addition, they are simpler because applications tend not to be littered with low level device-dependent implementation details.
In addition, applications need to be constructed in a manner in which access to device and software service functionality is done through an industry standard application programming interface (API) and not through details specific to one particular implementation of the device or software service. This allows applications to run with little or no modification on a greater variety of device configurations and automotive computing platform environments. This also allows applications to be added to the automotive computing platform throughout the life of the automobile, in particular, it enables third party software developers to construct applications to run on the automobile's computing platform.
AutoPC is an API set developed by Microsoft Corporation, which extends the WinCE operating system into the automotive industry. The WinCE operating system is an operating system available from Microsoft Corporation. AutoPC, however, uses the classic procedural approach of providing a set of data structures and function APIs to manipulate them.
With respect to securing access to various devices in an automobile, certain device functionality on the automobile(such as reading current oil pressure) may be benign and has little security issues. Other device functionality such as adjusting power seats, unlocking car doors, current GPS data, or manufacturer proprietary engine diagnostics data do have requirements for restricted access. Access to these devices or software services is important for certain applications, but uncontrolled access to these devices by any user over the internet (or directly connected) poses a security risk. As the automotive industry is concerned about the safety and security of their customers and in certain jurisdictions, mandated by law to do so, secure access to on-board device functionality is a requirement of automotive network computing.
Therefore, it would be advantageous to have a method and apparatus to allow an application written for the automotive computing platform to be designed and constructed in a modular, componentized fashion.
SUMMARY OF THE INVENTION
The present invention provides a method, apparatus, and instruction for use in an automotive computing environment for representing automotive device functionality and software services as software components of the automotive computing platform. A computing platform is used on a vehicle in which the computing platform is capable of executing computer program instructions written in the Java programming language. A plurality of program components written as JavaBeans from JavaBean components, which are used to represent device functionality and software services available on the computing platform. A component repository is employed such that software applications can determine the availability of the JavaBean components and establish access to any component's functionality using Java programming language method invocation.
The present invention provides a first mechanism used by applications to locate the component repository, this is known as repository discovery. A second mechanism is present for applications to query the repository to determine availability of components, this is known as component lookup. A third mechanism is available by which applications can gain access to components from the component repository.
REFERENCES:
patent: 5742914 (1998-04-01), Hagenbuch
patent: 5828840 (1998-10-01), Cowan et al.
patent: 5848581 (1998-12-01), Hirose et al.
patent: 6021307 (2000-02-01), Chan
patent: 6022315 (2000-02-01), IIiff
pat
Colson James Campbell
Graham Stephen Glen
Carstens Yee & Cahoon LLP
Cuchlinski Jr. William A.
Doudnikoff Gregory M.
International Business Machines - Corporation
Mancho Ronnie
LandOfFree
Method for representing automotive device functionality and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for representing automotive device functionality and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for representing automotive device functionality and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2524192