Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Protection at a particular protocol layer
Reexamination Certificate
1998-12-28
2003-06-03
Hayes, Gail (Department: 2131)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Protection at a particular protocol layer
C701S001000, C701S002000, C701S032000, C701S036000, C709S241000, C709S241000, C713S166000, C713S172000
Reexamination Certificate
active
06574734
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to an improved data processing system and in particular to a computer system within an automobile. Still more particularly, the present invention provides a method, system, and computer-readable code for selectively providing access to devices and software services in an automobile.
2. 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 selectively provide access to devices and software components through an automotive computing platform.
SUMMARY OF THE INVENTION
The present invention provides a method in a computing platform located in an vehicle for restricting access to a plurality of software components, wherein the plurality of software components are used to interface with a plurality of devices located within the vehicle. A request is received from an application for a software component, wherein the request includes a data structure and the software component is a requested software component. A determination is made as to whether the requested software component is present within the plurality of software components. An access level for the application is identified and a result is returned to the application based on whether the requested software component is present in the plurality of software components and based on the access level identified for the application.
The request made by the application may be for a type of software component. In this instance, a number of components may fall within the type of software components. Each of these components may provide a different level or amount of functionality. The actual component returned to the a
Colson James Campbell
Graham Stephen Glen
Carstens Yee & Cahoon LLP
Doudnikoff Gregory M.
Hayes Gail
Jackson Jenise
LandOfFree
Method and apparatus for securing access to automotive... 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 and apparatus for securing access to automotive..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for securing access to automotive... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3149016