Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 1 of 19
`
`
`
`
`Exhibit 1
`
`

`

`I IIIII IIIIIIII Ill lllll lllll lllll lllll lllll lllll lllll lllll 111111111111111111
`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 2 of 19
`US006629033B2
`
`(12) United States Patent
`Preston et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,629,033 B2
`Sep.30,2003
`
`(54) OPEN COMMUNICATION SYSTEM FOR
`REAL-TIME MULTIPROCESSOR
`APPLICATIONS
`
`(75)
`
`Inventors: Dan Alan Preston, Bainbridge Island,
`WA (US); Robert Pierce Lutter,
`Tacoma, WA (US)
`
`(73) Assignee: Medius, Inc., Seattle, WA (US)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by O days.
`
`(21) Appl. No.: 09/841,753
`
`(22) Filed:
`
`Apr. 24, 2001
`
`(65)
`
`Prior Publication Data
`
`US 2002/0156564 Al Oct. 24, 2002
`
`Int. Cl.7 .................................................. G06F 7/00
`(51)
`(52) U.S. Cl. ............................. 701/70; 701/33; 701/36;
`307/9.1
`(58) Field of Search .............................. 701/70, 33, 36,
`701/45, 41; 340/425.5; 307/9.1, 10.1, 10.2;
`709/400
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`6,161,071 A * 12/2000 Shuman et al. ............... 701/48
`6,243,450 Bl
`6/2001 Jansen et al.
`
`FOREIGN PATENT DOCUMENTS
`
`WO
`WO
`WO
`WO
`WO
`WO
`
`W096/24229
`W099/08436
`W099/57662
`W099/65183
`WOOl/30061
`WOOl/58110
`
`8/1996
`2/1999
`11/1999
`12/1999
`4/2001
`8/2001
`
`OTHER PUBLICATIONS
`
`Product description of Raytheon RT Secure, "Embedded
`Hard Real-Time Secure Operating System", Copyright
`2000, pp. 1-2.
`Product description of Raytheon RT Secure, Copyright
`2001, pp. 1-2.
`Product description of Raytheon RT Secure, "Development
`Environment", Copyright 2001, pp. 1-2.
`Product description of Raytheon Electronic Systems (ES),
`Copyright 2002, pp. 1-2.
`H. Chung, L. Ojeda, and J. Borenstein, "Sensor Fusion for
`Mobile Robot Dead-reckoning with a Precision-calibrated
`Fiber Optic Gyroscope", 2001 IEEE International Confer(cid:173)
`ence on Robotics and Automation, Seoul, Korea, May
`21-26, pp. 1-6.
`A. Das, R. Fierro, V. Kumar, J. Ostrowski, J. Spletzer, and
`C. Taylor, "A Framework for Vision Based Formation Con(cid:173)
`trol", IEEE Transactions on Robotics and Automation, vol.
`XX, No. Y, 2001, pp. 1-13.
`J. Takezaki, N. Ueki, T. Minowa, H. Kondoh, "Support
`System for Safe Driving-A Step Toward ITS Autonomous
`Driving-", Hitachi Review, vol. 49, No. 3, 2000, pp. 1-8.
`
`(List continued on next page.)
`
`Primary Examiner-Yonel Beaulieu
`(74) Attorney, Agent, or Firm---Marger
`McCollom, PC
`
`Johnson &
`
`(57)
`
`ABSTRACT
`
`A communication system for a mobile vehicle, home, or
`office environment includes multiple processors. The mul(cid:173)
`tiple processors each run an Open Communication system
`that controls how data is transferred between processors
`based on data content as opposed to the links that connect
`the processors together. The open communication system
`enables data or messages to be effectively transferred and
`processed for real-time applications or other server based
`applications that may be running on the multiple processors
`in a secure environment regardless of processors, locations,
`or data links.
`
`30 Claims, 9 Drawing Sheets
`
`12
`
`DISPLAY
`oc
`
`26
`
`10
`USER
`INTERFACE
`10
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 3 of 19
`
`US 6,629,033 B2
`Page 2
`
`OIBER PUBLICATIONS
`
`S.G. Goodridge, "Multimedia Sensor Fusion for Intelligent
`Camera Control and Human-Computer Interaction", Dis(cid:173)
`sertation submitted to the Graduate Faculty of North Caro(cid:173)
`lina State University in partial fulfillment of the require(cid:173)
`ments for the degree of Doctor of Philosophy in Electrical
`Engineering, Raleigh, NC, 1997, pp. 1-5.
`M. Chantler, G. Russel, and R. Dunbar, "Probabilistic Sen(cid:173)
`sor Fusion for Reliable Workspace Sensing", pp. 1-14.
`ISIS Project: Sensor Fusion, Linkoping University Division
`of Automatic Control and Communication Systems in coop(cid:173)
`eration with SAAB (Dynamics and Aircraft), 18 pp.
`Hitachi Automated Highway System (AHS), Automotive
`Products, Hitachi, Ltd., Copyright 1994-2002, 8 pages.
`Vehicle Dynamics Lab, University of California, Berkeley,
`funded by BMW, current members: D. Caveney and B.
`Feldman,"Adaptive Cruise Control", 17 pages.
`Counterair: The Cutting Edge, Ch. 2 "The Evolutionary
`Trajectory The Fighter Pilot-Here to Stay?" AF2025
`v3c8-2, Dec. 1996, pp. 1-7.
`Counterair: The Cutting Edge, Ch. 4 "The Virtual Trajectory
`Air Superiority without an "Air" Force?" AF2025 v3c8-4,
`Dec. 1996, pp. 1-12.
`
`TNO FEL Annual Review 1998: Quality works, 16 pages.
`Boeing News Release, "Boeing Demonstrates JSF Avionics
`Multi-Sensor Fusion", Seattle, WA, May 9, 2000, pp. 1-2.
`Boeing Statement, "Chairman and CEO Phil Condit on the
`JSF Decision", Washington, D.C., Oct. 26, 2001, pp. 1-2.
`Ada 95 Transition Support-Lessons Learned, Sections 3, 4,
`and 5, CACI, Inc. -Federal, Nov. 15, 1996, 14 pages.
`Joint Strike Fighter Terrain Database, ets-news.com "Simu(cid:173)
`lator Solutions" 2002, 3 pages.
`MSRC Redacted Proposal, 3.0 Architecture Development,
`pages 1-43.
`Powerpoint Presentation by Robert Allen-Boeing Phantom
`Works entitled "Real-Time Embedded Avionics System
`Security and COTS Operating Systems", Open Group Real(cid:173)
`Time Forum, Jul. 18, 2001, 16 pages.
`Green Hills Software, Inc., "The AdaMULTI 2000 Inte(cid:173)
`grated Development Environment", Copyright 2002, 7
`pages.
`Luttge, Karsten; "E-Charging API: Outsource Charging to a
`Payment Service Provider" IEEE; 2001 (pp. 216-222).
`
`* cited by examiner
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 4 of 19
`
`U.S. Patent
`
`Sep.30,2003
`
`Sheet 1 of 9
`
`US 6,629,033 B2
`
`>-
`I-.......
`a:::
`::::,
`(_)
`w
`en
`
`CX)
`
`....
`.....
`0~
`....
`co
`
`N
`.....
`
`(_)
`0
`
`....
`
`>-
`<t:
`_J
`a.
`en
`.......
`C)
`
`LO
`.....
`
`(_)
`0
`
`co
`N
`
`0
`.....
`
`w
`(_)
`a::: <t:
`wLL
`en a:::
`::::,W
`I-
`z
`.......
`
`0
`I")
`
`0
`
`....
`
`,...
`•
`-
`0
`u..
`
`w
`~ (_)
`<(
`0
`a:::
`CD
`
`0
`N
`
`0 .....
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 5 of 19
`
`10
`\
`
`APPLICATION (S)
`
`CAR INTERFACE
`MANAGER (API)
`
`PRIORITY MANAGER
`
`I
`I
`I
`I
`I
`I
`I
`
`'--50
`
`I
`I
`I
`I
`I
`I
`I
`
`APPLICATION (S)
`
`52-.....J
`
`CAR INTERFACE
`MANAGER (API)
`
`I
`I
`-4 - -
`I
`I
`I
`I
`46
`-..L
`I
`I
`I
`I
`
`CAR PROCESSOR #1
`COMMUNICATION
`CAR PROCESSOR #2
`10
`r----------------------------: Ltcyi~~[EOJ
`:----------------------------: )
`48
`
`PRIORITY MANAGER -4-
`
`44
`
`42
`
`I
`I
`I
`I
`-4 - -
`I
`I
`I
`
`LOGGING MANAGER
`
`LOGGING MANAGER
`
`SECURITY MANAGER
`
`SECURITY MANAGER
`
`I
`
`OPERA TING SYSTEM
`
`HARDWARE/LINKS
`INTERFACE
`
`------------1--------------
`
`OPERA TING SYSTEM
`
`HARDWARE/LINKS
`INTERFACE
`
`-------------- --------------
`
`I
`
`5t
`LINK
`FIG.2
`
`~ 40
`
`,- 38
`
`36
`
`d •
`r:JJ.
`•
`
`'JJ.
`~
`'?
`~ ~=
`
`N
`C
`C
`~
`
`'JJ. =-~
`~ ....
`N
`....,
`0
`\C
`
`e
`rJ'J.
`-..a-..
`a-..
`N
`'°
`b
`~
`~
`~
`N
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 6 of 19
`
`U.S. Patent
`
`Sep.30,2003
`
`Sheet 3 of 9
`
`US 6,629,033 B2
`
`........_
`60
`
`IDENTIFY OUT
`GOING MESSAGE
`
`44 )
`
`!
`
`62 ........_
`
`IDENTIFY PRIORITY
`VALUE ASSOCIATED
`WITH THE MESSAGE
`
`!
`
`64 ----
`
`RANK PRIORITY
`FOR
`IDENTIFIED
`MESSAGE
`
`!
`
`----
`66
`
`SEND MESSAGE TO
`LOGGING MANAGER
`
`FIG.3
`
`44 \
`
`IDENTIFY PRIORITY
`LABEL FOR
`INCOMING MESSAGE
`
`76
`
`REJECT
`MESSAGE
`
`N
`
`RETURN
`
`FIG.4
`
`PRIORITY SUFFICIENT
`TO RUN ON
`PROCESSOR
`y
`
`RANK PRIORITY
`WITH PRIORITIES FOR
`OTHER MESSAGES
`
`SCHEDULE PROCESSING
`OF MESSAGE ACCORDING
`TO PRIORITY RANKING
`
`RETURN
`
`68
`
`70
`
`72
`
`74
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 7 of 19
`U.S. Patent
`
`US 6,629,033 B2
`
`Sep. 30, 2003
`
`Sheet 4 of 9
`
`42 \
`
`RECEIVE MESSAGE
`
`i - -80
`
`1 I
`
`READ LOGGING
`LABEL IN MESSAGE
`
`---- 82
`
`, '
`
`N
`
`MESSAGE REQUIRE
`LOGGING ?
`
`----84
`
`lfy
`
`LOG MESSAGE IN
`MEMORY IDENTIFIED
`BY LOGGING LABEL
`
`----86
`
`--
`
`I J
`
`SEND MESSAGE TO
`NEXT COMMUNICATION ~ 88
`MANAGER
`
`RETURN)
`FIG.5
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 8 of 19
`
`U.S. Patent
`
`Sep.30,2003
`
`Sheet 5 of 9
`
`US 6,629,033 B2
`
`90
`\
`
`RECEIVE MESSAGE
`
`40
`
`)
`
`92
`\
`
`'
`SECURITY
`VALUE IDENTIFIED
`IN MESSAGE
`
`94
`~
`SECURITY VALUE y
`REQUIRED FOR
`APPLICATIONS
`
`N
`
`-
`
`9)6
`
`,Y
`
`SECURITY VALUE
`ACCEPT ABLE FOR
`CURRENT APPLICATIONS
`
`N
`
`y
`
`98
`\
`PASS MESSAGE TO
`NEXT COMMUNICATION
`LAYER
`
`RETURN)
`
`N
`
`100
`
`I
`
`)
`
`DROP
`-- MESSAGE
`
`RETURN
`
`FIG.6
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 9 of 19
`
`d •
`r:JJ.
`•
`
`102
`
`112
`
`130 110
`
`~ 1 08
`
`_DI-:-c- E::ER1~:T °rc,2s
`
`11,--7...----,_.......__,
`FUSION
`
`119
`
`114
`
`118
`
`122
`
`BRAKE
`
`SERIAL
`
`DOC
`
`DISPLAY
`
`._, BReE, 120
`DOC
`- - - 10
`125
`
`121
`
`FIG.7
`
`128,130
`
`140
`\
`TIME OF
`MEASUREMENT
`
`142
`\
`DATA
`
`PAYLOAD
`APPLICATION DAT A 139
`
`)
`
`I
`
`..
`
`I
`
`DOC
`
`104
`
`132
`\
`LINK
`HEADERS
`
`I
`
`134
`\
`SECURITY
`LABEL
`
`136
`\
`LOGGING
`LABEL
`
`138
`\
`PRIORITY
`LABEL
`
`..
`
`"
`QC LABELS 133
`OPERA TING SYSTEM DAT A 131
`FIG.8
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 10 of 19
`
`U.S. Patent
`
`Sep.30,2003
`
`Sheet 7 of 9
`
`US 6,629,033 B2
`
`150-- ~ 156
`
`154
`
`152
`
`SMALL, FAR
`
`158 -- AWAY OBJECT APPLICATION
`DETECTED
`------ -----
`,
`160 --
`ADD
`SECURITY
`LABEL
`,,
`DON'T
`LABEL FOR
`LOGGING
`
`OC SYSTEM
`10
`
`162 --
`
`f-.-.. 170
`
`LARGE, CLOSE
`IN OBJECT
`DETECTED
`----- ------
`"
`ADD
`SECURITY
`LABEL
`
`r--172
`
`',
`LABEL FOR
`LOGGING
`
`r--174
`
`,
`LABEL
`AS LOW
`PRIORITY
`
`164 '--
`
`'
`FORMAT FOR
`
`166 .-- LINK TO FUSION
`
`PROCESSOR
`
`~
`106,112
`
`/
`
`----176
`
`'
`LABEL
`AS HIGH
`PRIORITY
`,
`FORMAT FOR
`LINK TO FUSION ----178
`PROCESSOR
`
`.--
`
`168
`
`It
`
`TRANSMIT
`DATA
`
`,
`
`TRANSMIT
`DATA
`
`----180
`
`FIG.9
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 11 of 19
`U.S. Patent
`
`US 6,629,033 B2
`
`Sep.30,2003
`
`Sheet 8 of 9
`
`182
`\
`
`RECEIVE
`TRACK
`REPORT
`
`114
`
`)
`
`I
`
`PROCESS
`FOR RECEIVED
`INTERFACE
`
`READ
`SECURITY
`LABEL
`
`READ
`LOGGING
`LABEL
`
`, r
`
`READ
`PRIORITY
`LABEL
`
`SEND
`REPORT TO
`APPLICATION
`
`•
`SEND
`BRAKE
`COMMAND
`
`FIG.10
`
`1 I
`
`194
`\
`SEND IMAGE
`TO DATA
`DISPLAY
`
`1 I
`
`SEND AUDIO
`DATA TO CAR
`AUDIO SYSTEM
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 12 of 19
`
`IR SENSOR
`
`200
`
`d •
`r:JJ.
`•
`
`220
`)
`
`IR PROCESSING
`(APPLICATION)
`
`PROCESSOR A
`
`PROCESSOR B
`
`FUSION PROCESSING
`(APPLICA TIONl
`
`l
`
`218
`
`CONNECT TO SEND (SENSOR REPORT)
`
`CONNECT TO RECEIVE (SENSOR REPORT)
`
`202
`
`204
`
`2~6
`
`l
`l
`l
`
`SEND (SENSOR REPORT)
`
`OPEN CONNECTION
`SYSTEM
`
`HARDWARE INTERFACE
`
`269
`210
`\
`,
`212--
`1 SENSOR REPORT 1
`
`CONTROL TABLE
`SENSOR REPORT
`i.---. 213 PRIORITY
`\.. SECURITY
`FUSION APP.
`LOGGING
`CONNECT TO SEND ( )
`CONNECT TO RECEIVE ( )
`SEND ( )
`WAIT ON( )
`
`CONTROL TABLE
`
`SENSOR REPORT
`PRIORITY
`SECURITY
`PROCESSOR A
`PROCESSOR C
`LOGGING
`BRAKE REPORT
`PRIORITY
`SECURITY
`BRAKE PROC.
`CONNECT TO SEND ( )
`CONNECT TO RECEIVE ( l
`WAIT ON( )
`
`l
`l
`
`216
`\
`WAIT ON(SENSOR REPORT)
`
`10
`)
`OPEN CONNECTION
`SYSTEM
`
`HARDWARE INTERFACE
`
`r--214
`
`FIG.11
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 13 of 19
`
`US 6,629,033 B2
`
`1
`OPEN COMMUNICATION SYSTEM FOR
`REAL-TIME MULTIPROCESSOR
`APPLICATIONS
`
`5
`
`2
`FIG. 2 is a block diagram of the open communication
`system shown in FIG. 1.
`FIG. 3 is a flow diagram showing how a priority manager
`processes outgoing data in the open communication system.
`FIG. 4 is a flow diagram showing how the priority
`manager receives data in the open communication system.
`FIG. 5 is a flow diagram showing how a logging manager
`processes data in the open communication system.
`FIG. 6 is a flow diagram showing how a security manager
`processes data in the open communication system.
`FIG. 7 is a diagram showing one example of how the open
`communication system is used by different processors.
`FIG. 8 is a diagram of a tracking report that is generated
`15 by the open communication system.
`FIG. 9 is a flow diagram showing how different image
`data is processed and transmitted using the open communi(cid:173)
`cation system.
`FIG. 10 is a flow diagram showing how the transmitted
`image data in FIG. 9 is received and processed using the
`open communication system.
`FIG. 11 is a block diagram showing another example of
`how the open connection system operates.
`
`DETAILED DESCRIPTION
`
`BACKGROUND
`Cars include many different electro-mechanical and elec(cid:173)
`tronic systems. Examples include braking systems, elec(cid:173)
`tronic security systems, radios, Compact Disc (CD) players,
`internal and external lighting systems, temperature control
`systems, locking systems, seat adjustment systems, speed 10
`control systems, mirror adjustment systems, directional
`indicators, etc. Generally the processors that control these
`different car systems do not talk to each other. For example,
`the car radio does not communicate with the car heating
`system or the car braking system. This means that each one
`of these car systems has to provide a separate standalone
`operating system. For example, separate processors and
`separate user interfaces are required for the car temperature
`control system and for the car audio system. Many of these
`different car processors may be underutilized since they are 20
`only used intermittently.
`Even when some processors in the car do talk to each
`other, they are usually so tightly coupled together that it is
`impossible to change any one of these processors without
`disrupting all of the systems that are linked together. For 25
`example, some cars may have an interface on the dashboard
`that controls both internal car temperature and a car radio.
`The car radio cannot be replaced with a different model and
`still work with the dashboard interface and the car tempera(cid:173)
`ture controller.
`Integration of new systems into a car is also limited. Car
`systems are designed and selected well before the car is ever
`built. A custom wiring harness is then designed to connect
`all the car systems selected for the car. A car owner can not
`later incorporate new systems into the existing car. For
`example, a car may not originally come with a car naviga(cid:173)
`tion system. An after market navigation system from another
`manufacturer cannot be integrated into the car.
`Because after market devices can not be integrated into
`car control and interface systems, it is often difficult for the 40
`driver to try and operate these after market devices. For
`example, the car driver has to operate the after market
`navigation system from a completely new interface, such as
`the keyboard and screen of a laptop computer. The driver
`then has to operate the laptop computer, not from the front 45
`dashboard of the car, but from the passenger seat of the car.
`This makes many after market devices both difficult and
`dangerous to operate while driving.
`The present invention addresses this and other problems
`associated with the prior art.
`
`FIG. 1 shows a car 12 that includes multiple processors
`14, 16, 18 and 20. The engine monitor processor 14 in one
`configuration monitors data from different sensors 22 and 24
`30 in the car engine. The sensors 22 and 24 can be any sensing
`device such as sensors that monitor water temperature, oil
`temperature, fuel consumption, car speed, etc. The brake
`control processor 20 monitors and controls an Automatic
`Braking System (ABS) 28. The display processor 16 is used
`35 to control and monitor a graphical or mechanical user
`interface. The security processor 18 monitors and controls
`latches and sensors 30 and 32 that are used in a car security
`system.
`Typical networks, such as in an office network
`environment, enable multiple computers to communicate
`with each other. Applications such as printing jobs can be
`launched from any one of the networked computers. If one
`of the networked computers crashes or is busy, a user must
`manually send the job to another computer. The other
`computer then handles the task like any other locally
`received task.
`In a car environment, tasks must be processed with
`different priorities in real-time. For example, the braking
`tasks in the brake processor 20 have to be processed with a
`high priority while a radio selection task performed in the
`display processor 16 can be processed with a relatively low
`priority. The processors 14, 16, 18 and 20 all include
`software that runs an Open Communication (OC) system 10
`55 that enables the multiple processors to transfer data and
`exchange messages for performing these real-time car appli-
`cations.
`If the processor 20 currently running the high priority
`braking application fails, the OC system 10 allows the
`braking tasks to be offloaded to another processor in car 12,
`such as the display processor 16. The OC system 10 auto(cid:173)
`matically assigns a high priority to the braking tasks that
`allow the braking tasks to override lower priority tasks, such
`as the radio application, that are currently being performed
`65 in display processor 16.
`The OC system 10 also ensures that data in each processor
`is processed in a secure manner for the car environment. The
`
`50
`
`SUMMARY OF THE INVENTION
`A communication system for a mobile vehicle, home, or
`office environment includes multiple processors. The mul(cid:173)
`tiple processors each run an Open Communication system
`that controls how data is transferred between processors
`based on data content as opposed to the links that connect
`the processors together. The open communication system
`enables data or messages to be effectively transferred and
`processed for real-time applications or other server based 60
`applications that may be running on the multiple processors
`in a secure environment regardless of processors, locations,
`or data links.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a diagram of a car that have multiple processors
`that each run an open communication system.
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 14 of 19
`
`US 6,629,033 B2
`
`3
`security portion of the OC system 10 prevents unauthorized
`devices from accessing the different car applications. The
`OC system 10 also includes a logging portion that allows
`data in the car system to be automatically logged. This is
`important for accident reconstruction purposes. The OC
`system 10 also allows different processors to communicate
`over different communication protocols and hardware inter(cid:173)
`faces. Any processor that includes an OC system 10 can be
`integrated in the system shown in FIG. 1. This allows
`different processors and different applications can be seam(cid:173)
`lessly replaced and added to the overall multiprocessor
`system.
`The description below gives only a few examples of the
`different processors and different applications that can
`implemented using the OC system 10. However, any single 15
`or multiprocessor system located either inside or outside of
`car 12 can communicate and exchange data using the OC
`system 10. It should also be understood that the OC system
`10 can be used in any real-time network environment such
`as between processors used in appliances and computers in 20
`the home.
`FIG. 2 is a block diagram of the communication managers
`used in the OC system 10 described in FIG. 1. The different
`communication managers in the OC system 10 are config(cid:173)
`ured to provide the necessary control for operating a dis(cid:173)
`tributed processor system in a real-time car environment.
`Applications 48 are any of the different applications that can
`be performed for the car 12 shown in FIG. 1. For example,
`applications can include car displays, braking control, secu(cid:173)
`rity systems, sensor monitoring, airbag deployment, etc. One 30
`or more applications can be run in the same processor at the
`same or at different times.
`A car interface manager 46 operates as an Application
`Programmers Interface (API) that can be implemented in
`any variety of different languages such as Java, C++, Exten(cid:173)
`sible Markup Language (XML) or HyperText Markup Lan(cid:173)
`guage (HTML), etc. The car interface manager 46 enables
`applications 48 to be written in any variety of different
`languages. This prevents the applications 48 from having to
`be written specifically for the car environment or for a
`specific communication protocol. Thus, applications written
`for other systems can be reused in the car system described
`below. The car interface manager 46 reads basic processing
`and data transfer commands needed to transfer data and 45
`messages between different processors and storage mediums
`inside or outside the car 12.
`For clarity the terms 'message' and 'data' are used inter(cid:173)
`changeably below. After a message passes through the car
`interface manager 46, a priority manager 44 determines a
`priority value for the message that determines how the
`message is processed both in the local processor 50 and in
`other processors such as processor 52. Referring to FIG. 3,
`an outgoing message is identified by the priority manager 44
`in block 60. A priority for the message is identified in block
`62 by reading a priority value that the generic car interface
`manager 46 has attached to the message.
`In block 64, the priority manager 44 compares the priority
`value for the outgoing message with the priority values for
`other messages in the processor. The priority manager 44
`ranks the outgoing message with respect to the other mes(cid:173)
`sages and then sends the message to the logging manager 42
`in block 66 (FIG. 2). For example, there may be several
`messages that either need to be output or received by a
`particular processor. An output message with a high priority
`value, such as a crash indication message, will be assigned
`higher priority than other messages and will therefore be
`
`4
`immediately transmitted by the processor 50 before other
`lower priority messages.
`FIG. 4 shows how the priority manager 44 receives
`messages from other processors. There may be multiple
`5 applications running on the same processor and multiple
`messages and data sent from other processors to those
`applications. For example, multiple sensors may be sending
`different types of data to a video display application running
`on one of the processor 50 (FIG. 2). That same processor 50
`10 may also be receiving different types of sensor data for
`running an airbag deployment application. The priority
`manager 44 determines the order that messages are pro(cid:173)
`cessed by the different applications that reside on processor
`50.
`In block 68, the priority manager 44 reads the priority
`labels for incoming messages. If the priority of the message
`is not high enough to run on the processor in block 70, the
`data or message is rejected in block 76. The priority manager
`44 may send out a message to the sending processor indi-
`cating the message has been rejected. In some situations, the
`message or data may have such a low priority that an
`acknowledge message does not have to be sent back to the
`sending processor. For example, inside temperature data
`from a temperature sensor may be sent to one or more
`25 processors with no requirement that the processor accept or
`acknowledge the data. In this case the temperature data is
`sent with a very low priority value that indicates to the
`priority manager 44 that no message needs to be sent back
`to the temperature sensor even if the data is rejected.
`The priority manager 44 in block 72 ranks the priority of
`the incoming message in relation to the priorities of all the
`other messages in the processor. The priority manager in
`block 74 decides according to the ranking whether the
`message should be put in a queue or sent directly to the
`35 application for immediate processing. For example, a crash
`indication message may have a high enough priority to cause
`the priority manager 44 to delay all data currently being
`processed by all other applications in the same processor.
`The priority manager 44 directs all the applications to wait
`40 while the current high priority crash indication message is
`processed. The other data and messages are queued in the
`processor and processed after the crash indication message
`has been completed.
`Referring to FIGS. 2 and 5, a logging manager 42 controls
`what data is logged by different processors. It may be
`important to log critical failures that occur during an acci(cid:173)
`dent. For example, it may be important to verify that a
`particular processor sent an air bag deployment message and
`that another processor successfully received the airbag
`50 deployment message. This would allow insurance compa(cid:173)
`nies and other entities to reconstruct accidents by identifying
`when and where different messages were sent and received.
`The logging manager 42 receives either an incoming
`message over a communications link for sending to a local
`55 application 48 or receives an outgoing message from one of
`the local applications 48 for sending out over the commu(cid:173)
`nications link to another processor in block 80. The logging
`manager 42 reads a logging label in the message in block 82.
`If the logging label indicates that no logging is required, the
`60 message is sent on to the next communication manager in
`block 88. If it is an outgoing message it is sent to the security
`manager 40 (FIG. 2). If it is a incoming message it is sent
`to the priority manager 44. If the message requires logging,
`the logging manager 42 stores the message in a memory in
`65 block 86. The logging label may indicate a particular type of
`memory for logging, such as a nonvolatile Flash memory or,
`if available, a high volume hard disk peripheral memory.
`
`

`

`Case 6:20-cv-01001-ADA Document 1-2 Filed 10/28/20 Page 15 of 19
`
`US 6,629,033 B2
`
`15
`
`20
`
`5
`The logging manager 42 in each processor, provides the
`OC system 10 with the unique ability to track when and
`where messages are sent and received at different processors
`in the multiprocessor car system. This is important in
`accident reconstruction allowing the logging managers 42 to
`identify which processors and applications failed and also
`the sequence in which the different processors and associ(cid:173)
`ated applications failed.
`The logging manager 42 can also track unauthorized
`messages and data that may have caused any of the proces- 10
`sors in the car to crash. For example, an audio processor that
`handles audio applications in the car may crash due to
`unauthorized downloading of MP3 music from a laptop
`computer. The logging manager 42 can log the unauthorized
`data received from the laptop MP3 player. The logging
`manager 42 logs any data that does not have a particular
`security or priority label value. A system administrator can
`then down load the MP3 data to identify what caused the
`audio processor to crash.
`Referring to FIGS. 2 and 6, a security manager 40
`provides security for applications both receiving and trans(cid:173)
`mitting messages. For instance, a laptop computer may be
`connected to a Ethernet port in the car 12 (FIG. 1). If the
`laptop computer does not use the OC system 10, data from
`that laptop application is not allowed to access certain 25
`processors or certain applications in the car 12. For example,
`audio data should not be sent or processed by a processor
`that performs car braking control.
`The security manager 40 in block 90 reads a message
`either received from an application on the same processor or 30
`received over a communication link from another processor.
`The security manager 40 determines if there is a security
`value associated with the message in block 92. If there is no
`security value associated with the data, the security manager
`40 may drop the data in block 100. However, some 35
`applications, such as a processor that plays audio data may
`not require a security label. In this case, the security manager
`in block 94 allows the data to be passed on to the application
`in block 98.
`In other instances the data or message may have a security
`value, but that security value is not sufficient to allow
`processing on the present applications. For example, data for
`car security monitoring may be sent to a processor that
`controls air bag deployment and an automatic braking
`system. The two currently running applications may set a
`minimum security level for receiving data. If data received
`from other processors do not have that minimum security
`level in block 96, the data is dropped in block 100.
`Otherwise, the data or message is passed on to the next
`communication layer for further processing in block 98.
`Thus the security manager 40 prevents unauthorized data or
`messages from effecting critical car applications.
`Referring back to FIG. 2, an operating system layer 38
`identifies the communication platform used for communi(cid:173)
`cating the data or message over a link identified in a 55
`hardware/link interface 36. The operating system 38 then
`formats the message for the particular communication stack
`and medium used by the identified link 54. For example, the
`operating system layer 38 may identify a first message being
`transmitted over a Bluetooth wireless link and a second 60
`message transmitted over a Transmission Control Protocol/
`Internet Protocol (TCP/IP) packet switched link. The data or
`message adds whatever headers and formatting is necessary
`for transmitting the first message over the Bluetooth wireless
`link and the second message over the TCP /IP hardwired link.
`The hardware/link interface 36 includes the software and
`hardware necessary for interfacing with different communi-
`
`6
`cation links 54. For example, the two processors 50 and 52
`may communicate over a Ethernet link, 802.11 wireless link,
`or hardwired Universal Serial Bus link, etc. The software
`necessary for the two processors to communicate over these
`5 different interfaces is known to those skilled in the art and
`is therefore not described in further detail.
`FIG. 7 describes one example of an application that uses
`the OC system 10 described above in FIGS. 1-6. A car 102
`includes an radar sensor 104 that is controlled by a radar
`processor 106. The radar sensor 104 is located in the front
`grill of car 102. An InfraRed (IR) sensor 110 is controlled by
`an IR processor 112 and is located on the front dash of car
`102. A braking system 123 is controlled by a brake control
`processor 122. The IR processor 112 is connected to a fusion
`processor 114 by an Ethernet link 116 and the radar proces(cid:173)
`sor 106 is connected to the fusion processor 114 by a 802.11
`wireless link 108. The brake processor 122 is connected to
`the fusion processor 114 by a CAN serial link 120. The
`fusion processor 114 is also coupled to a display screen 118.
`The radar sensor 104 in combination with the radar
`processor 106 generates Radar Track Reports (RTRs) 130
`that are sent to the fusion processor 114. The IR sensor 110
`in combination with the IR processor 112 generate Infrared
`Track Reports (ITRs) 128 that are sent to the fusion pro(cid:173)
`cessor 114.
`Referring to FIG. 8, each track report 128 and 130
`includes communication link headers 132 for communicat(cid:173)
`ing over an associated interface medium. In this example,
`the radar track report 130 includes the link headers 132
`necessary for transmitting data over the 802.11 link 108. The
`infrared track report 128 includes the link headers 132 for
`transmitting data over the Ethernet link 116.
`The track reports 128 and 130 include Open Communi(cid:173)
`cation (OC) labels 133 for performing the OC operations
`described above. A security label 134 is used by the security
`manager for preventing unauthorized data from being down(cid:173)
`loaded into one of the car processors and disrupting appli(cid:173)
`cations. A logging label 136 is used by the logging manager
`40 to identify data that needs to be logged in a local memory.
`The priority label 138 is used by the priority manager for
`scheduling messages or data to the applications run by the
`processors. The link headers 132, security label 134, logging
`label 136 and priority label 138 are all part of the data 131
`45 used by the open operating system 131.
`The radar processor 106 and IR processor 112 also send
`a time of measurement 140 and other data 142 from the radar
`sensor 104 and IR sensor 110, respectively. The data 142 can
`include kinematic states of objects detected by the sensors.
`50 The time of measurement data 140 and ot