System-on-chip device that performs network switching operations and direct actuator driving operations

Abstract

The present invention relates to a System-On-Chip device that performs network switching operations and operations to directly drive an actuator, comprising: a CPU subsystem configured with multiple high-performance cores based on electrically isolated hypervisorless architecture to execute multiple applications; a Micro Control Unit (MCU) subsystem that calculates device command data or an operation result value for driving an actuator from a signal input to the System-On-Chip; a network device that routes the signal input to the System-On-Chip and transmits the input signal to a specific port within the System-On-Chip; and an actuator driving signal generator that generates an actuator driving signal for driving an actuator connected to the System-On-Chip using the command data or the operation result value for driving the actuator.

Description

Technology Field

[0001] The present invention relates to a vehicle control system and a control method, and more specifically, to a vehicle control system and a control method for controlling a device or actuator within a vehicle. Background Technology

[0002] Various devices such as engine / motor, steering, brake system, airbag, headlights, climate control unit, side mirror, seat, mood lamp, power window, door lock, soft closing, trunk door lock, power trunk, taillight, wiper, rear curtain, washer, sunroof ring, etc., and an electronic control unit or electronic control unit (ECU) that controls each of these may be used, such as wireless charging, telescopic, infotainment system, etc.

[0003] The electronic control unit (ECU) collects information from all sensors installed in the vehicle and manages the operation of actuators, and dozens to hundreds of electronic control units (ECUs) can be used in a single vehicle.

[0004] Automotive wiring harnesses can be used to supply the power necessary to operate all electrical components within the vehicle and to transmit electrical signals to each electronic control module.

[0005] With the recent commencement of development in electric and autonomous vehicles, the number of electronic control units (ECUs) has increased, and the number of wiring harnesses has also increased significantly.

[0006] As such, due to the increased number of electronic control units (ECUs) and wiring harnesses resulting from the development of electric and autonomous vehicles, vehicle wiring becomes more complex, and fuel efficiency decreases due to the increased vehicle weight.

[0007] To address the problems caused by the increase in electronic control units (ECUs) and wiring harnesses, modular electronic control units (Modular ECUs) have emerged, integrating a single module to perform engine / motor control, transmission control, and vehicle safety system management. Additionally, architectures are being introduced that group ECUs by function into domains or zones, controlling various in-vehicle functions through communication between domains or zones.

[0008] However, a failure of the integrated ECU or an error in a specific communication node can significantly affect the operation of the entire in-vehicle system, which may lead to a decrease in vehicle stability and safety; in particular, if a problem occurs in the Electronic Control Unit (ECU) responsible for critical functions, it can result in serious consequences.

[0009] Furthermore, existing vehicle systems have limited capabilities for immediately detecting and recovering from errors. This can negatively impact vehicle safety, particularly in the event of a failure, and makes real-time error recovery difficult in complex systems. Additionally, the simple redundancy or fail-safe mechanisms of existing systems are designed to maintain only minimal functionality even if a part of the system fails. Moreover, if a specific ECU fails, the corresponding vehicle system shuts down, making cooperation with other systems impossible. Additionally, while existing vehicle systems were effective for controlling existing vehicle functions, they lack the scalability required to integrate autonomous driving, V2X (Vehicle-to-Everything) communication, and various new technologies. This can lead to difficulties in upgrading existing vehicle systems or adding new features as technology advances.

[0010] Many ECUs may be running different software versions, and it is not easy for existing vehicle systems to manage and update them integrally. In particular, when a software defect is discovered, it is difficult to quickly fix it across the entire vehicle system.

[0011] Because data is not processed centrally, there are limitations in effectively analyzing and utilizing the large volume of data generated within the vehicle. This can pose a problem, particularly in vehicle systems that require real-time processing of massive amounts of data, such as autonomous driving.

[0012] However, centralized vehicle systems can have the problem that if an error occurs in the centralized computing unit, it can lead to a failure in the entire vehicle system, potentially causing a serious accident. The problem to be solved

[0013] Embodiments of the present invention can provide various vehicle systems that enhance recovery functions for the vehicle system and data even when errors occur in hardware or transmitted data within the vehicle system in a vehicle system that directly controls in-vehicle devices and actuators.

[0014] However, the problem to be solved by the present invention is not limited thereto and may be extended in various ways within an environment that does not deviate from the spirit and scope of the present invention. means of solving the problem

[0015] According to one embodiment of the present invention, a System-On-Chip device that performs network switching operations and operations to directly drive an actuator may include: a CPU subsystem configured with a plurality of high-performance cores based on electrically isolated hypervisorless architecture to execute a plurality of applications; a Micro Control Unit (MCU) subsystem that calculates device command data or an operation result value for driving an actuator from a signal input to the System-On-Chip; a network device that routes the signal input to the System-On-Chip and transmits the input signal to a specific port within the System-On-Chip; and an actuator driving signal generator that generates an actuator driving signal for driving an actuator connected to the System-On-Chip using the command data or the operation result value for driving an actuator.

[0016] The network device is connected to an in-vehicle control device outside the system-on-chip, and the network device may include at least one of Ethernet, CAN, and LIN communication ports.

[0017] The above CPU subsystem can calculate command data or a calculation result value for actuator driving using the in-vehicle device command signal or the sensor data.

[0018] The above command data represents a target operation or target state of a target device targeted by the command data, and the operation result value for driving the actuator includes control parameters of a driving signal for achieving the target operation or target state of the target device included in the command data, the driving signal includes a pulse signal, and the control parameters include at least one of a prescale value, a counter value, a comparison value, a clock distribution value, a signal period, a signal pattern, and a signal amplitude, wherein the target device may include a vehicle driving, steering, braking, and body device.

[0019] Each of the above CPU subsystem, the above MCU subsystem, and the above network device derives clock signals of different frequencies, and the clock signals of different frequencies may be independent of each other.

[0020] The actuator driving signal generator includes a clock interface, and the clock interface receives at least two of the at least one system clock signals of different frequencies that are independent of each other, and can select one of the at least two system clocks as the system clock based on normal operation.

[0021] The actuator driving signal generator includes a register interface and a register, wherein the register interface receives at least one clock distribution value or at least one operation result value for actuator driving from the CPU subsystem, the MCU subsystem, or the network device, and can store the received at least one clock distribution value and the at least one operation result value for actuator driving at their respective corresponding addresses in the register.

[0022] The actuator driving signal generator includes a clock generator, and the clock generator can generate a clock signal using the system clock transmitted from the clock interface and the clock distribution value transmitted from the register.

[0023] The actuator driving signal generator includes at least two pulse signal generating modules, and each of the at least two pulse signal generating modules can generate an actuator driving signal using a clock signal transmitted from the clock generator and an actuator driving operation result value transmitted from the register.

[0024] The above driving signal generator can transmit a pre-set clock distribution value and an operation result value for driving an actuator to the clock generator and the pulse signal generation module, respectively, in correspondence with each case stored in the register, when the system clock is changed or an error occurs in the path between the clock generator and the at least one pulse signal generation module.

[0025] The above register includes a safety control value, and when an actuator connected to the driving signal generator exceeds a threshold value of the state required by the command data, the driving signal generator transmits the safety control value to the pulse signal generation module, wherein the safety control value may include an operation result value for driving an actuator that stops the actuator or maintains it in a safe state.

[0026] When the register interface receives a direct control signal from an upper system, the register interface directly transmits the result of an operation for driving an actuator received after receiving the direct control signal to the pulse signal generation module, wherein the upper system may include the CPU subsystem, the MCU subsystem, or the network device.

[0027] At least some of the above-mentioned at least two pulse signal generation modules are simultaneously activated and operate in a complementary manner, wherein the register can transmit at least two clock distribution values ​​and at least two operation result values ​​for actuator driving to the clock generator and the at least two pulse signal generation modules, respectively.

[0028] When an actuator related to the target device directed by the above input signal is connected to the system-on-chip, the network device can extract command data and a calculation result value for driving the actuator from the above input signal and transmit them to the driving signal generator.

[0029] Meanwhile, as a zone control unit for controlling in-vehicle devices connected to a vehicle network, it may include a Micro Control Unit (MCU) subsystem that calculates device command data or an operation result value for actuator driving from a signal input to the system-on-chip, a network device that routes the signal input to the system-on-chip and transmits the input signal to a specific port within the system-on-chip, and an actuator driving signal generator that generates an actuator driving signal for driving an actuator connected to the system-on-chip using the command data or the operation result value for actuator driving. Effects of the invention

[0030] The disclosed technology may have the following effects. However, this does not mean that a specific embodiment must include all of the following effects or only the following effects; therefore, the scope of the rights of the disclosed technology should not be understood as being limited by this.

[0031] The vehicle control system and control method according to the embodiments of the present invention enable precise synchronization between zone control units, thereby ensuring that the transmission delay time for control signals is constant for each in-vehicle device and actuator.

[0032] A vehicle control system and control method according to embodiments of the present invention can continuously control a target actuator without interruption even when an error occurs in a driving computation device of a central control unit or a zone control unit.

[0033] A vehicle control system and control method according to embodiments of the present invention provide a plurality of control paths for a major actuator in a vehicle, thereby ensuring uninterrupted control of the major actuator even if a problem occurs in a specific path.

[0034] A vehicle control system and control method according to embodiments of the present invention can reduce the processing delay of messages for urgent and important actuators among a plurality of input messages.

[0035] In a vehicle control system and control method according to embodiments of the present invention, a central control unit or a zone control unit can continuously control a target actuator without interruption through the generation of a driving signal for the actuator and the redundancy of the path within its own integrated circuit.

[0036] A vehicle control system and a control method according to embodiments of the present invention can provide a vehicle control system capable of accurately and quickly determining the transmission path of a command signal to a target device.

[0037] A vehicle control system and control method according to embodiments of the present invention can reduce design time and implementation IP costs by using the same actuator drive unit within a zone control unit and an electronic control unit (ECU).

[0038] A vehicle control system and control method according to embodiments of the present invention can reduce the number of expensive computing devices and improve functional safety by directly controlling a signal generation module for driving an actuator within a central control unit or a zone control unit using a register control method.

[0039] A vehicle control system and control method according to embodiments of the present invention can accurately transmit data to a target device even if data manipulation caused by external intrusion into a vehicle network or vehicle control device, an error on a signal transmission path, or an error in a computing device on a path where data is transmitted occurs, and can control a target actuator to a pre-set safety level if the transmitted command data violates a pre-set rule.

[0040] A vehicle control system and control method according to embodiments of the present invention can rapidly and accurately transmit and process actuator command data by automatically generating a frame using a pre-written reference table based on information of a device where an actuator operation command is generated.

[0041] A vehicle control system and control method according to embodiments of the present invention can easily expand an existing system when adding new devices or functions, and minimize system changes when introducing new functions or upgrading a vehicle.

[0042] A vehicle control system and control method according to embodiments of the present invention can transmit data of integrity by filtering out erroneous data through a zone control unit within a vehicle network by comparing data from its own calculations with received data.

[0043] A vehicle control system and a control method according to embodiments of the present invention can rapidly detect an error occurring within the system and take appropriate countermeasures through a multi-core system and a register-based control structure.

[0044] The vehicle control system and control method according to the embodiments of the present invention provide consistent control of the entire vehicle system and monitor and control the entire vehicle system using a centralized control method, thereby enabling effective management of data generated in each zone of the vehicle and efficient allocation of necessary resources. Brief explanation of the drawing

[0045] FIG. 1a is a configuration diagram of a vehicle network (1) capable of controlling multiple zones within a vehicle. FIG. 1b is an internal block diagram of a zone control unit (150) constituting a vehicle control system (1-1) that controls a plurality of zones within a vehicle according to a comparative embodiment of the present invention. FIG. 2a is a schematic diagram of a vehicle control system (2-1) for a vehicle zone architecture network. FIG. 2b is a schematic diagram of a vehicle control system (2-2) for a vehicle's zone architecture network. FIG. 3 is a schematic diagram of a vehicle control system (2-3) for a vehicle zone architecture network according to one embodiment of the present invention. FIG. 4 is a schematic diagram of a vehicle control system (2-4) according to another embodiment of the present invention. FIG. 5 is a diagram showing the signal flow of a vehicle control system (3) according to another embodiment of the present invention. FIG. 6 is a schematic diagram of a vehicle control system (4) capable of controlling a plurality of zones within a vehicle according to another embodiment of the present invention. FIG. 7 is a block diagram showing a partial internal configuration of a vehicle control system (5) according to another embodiment of the present invention. FIG. 8 is a block diagram of a device (6) for controlling a device inside a vehicle according to a comparative embodiment of the present invention. FIGS. 9a and 9b are block diagrams of a device (7-1, 7-2) for controlling a device inside a vehicle according to one embodiment of the present invention. FIGS. 10a and 10b are schematic block diagrams of a vehicle control system (800) according to another embodiment of the present invention. FIG. 11 is an internal configuration block diagram of a vehicle control system (9) that forms a vehicle network according to another embodiment of the present invention. FIG. 12 is a block diagram showing a detailed internal configuration of a central control unit (10) according to one embodiment of the present invention. FIG. 13 is a block diagram showing a detailed internal configuration of a central control unit (11) according to another embodiment of the present invention. FIG. 14 is a block diagram showing a detailed internal configuration of a first zone control unit (12) according to another embodiment of the present invention. FIG. 15 is a drawing illustrating a method for directly controlling an actuator of a first zone control unit (13) according to another embodiment of the present invention. FIG. 16 is a diagram showing a signal path within a zone control unit (1400) in a vehicle control system (14) for a zone architecture according to another embodiment of the present invention. FIGS. 17a through 17d are drawings showing some operation of the network subsystem (1330) of FIGS. 14 and FIG. 15 corresponding to the first path (A) shown in FIG. 16. FIG. 18 is a drawing showing the components and operation of a network device (16) according to one embodiment of the present invention. FIG. 19 is an internal block diagram of a first zone control unit (17) using register mirroring according to another embodiment of the present invention. FIG. 20 is a block diagram showing a detailed internal configuration of a first zone control unit (18) according to another embodiment of the present invention. FIG. 21 is a block diagram showing a detailed internal configuration of a first zone control unit (19) according to another embodiment of the present invention. FIG. 22 is a block diagram of a vehicle control device (20) that generates a signal for driving an actuator according to one embodiment of the present invention. FIG. 23 is a block diagram of an input / output subsystem (21) composed of a plurality of GPSB (General Purpose Serial Bus) controllers according to an embodiment of the present invention. FIG. 24 is a block diagram of an input / output subsystem (22) according to another embodiment of the present invention. FIGS. 25 and 26 are block diagrams of a vehicle control system (23, 24) including an electronic control unit (ECU) (2310, 2440, 2450) with enhanced functional safety of actuator control according to another embodiment of the present invention. FIG. 27 is a block diagram of a vehicle control device (25) that directly controls an actuator in a vehicle according to another embodiment of the present invention. FIG. 28 is an internal block diagram of a zone control unit (26) used in a vehicle zone architecture network according to another embodiment of the present invention. FIGS. 29 and FIGS. 30 are internal block diagrams of zone control units (27, 28) used in a zone architecture network within a vehicle, as variations of FIG. 28. FIG. 31 is an internal block diagram of a drive control unit (29) according to one embodiment of the present invention. FIG. 32 is an internal block diagram of a network device (30) within a zone control unit including a path controller (3005) according to another embodiment of the present invention. FIGS. 33a and FIGS. 33b are internal block diagrams of a network device (31) within a zone control unit according to another embodiment of the present invention. FIG. 34 is a schematic diagram of a centralized vehicle control system (32) in which an in-vehicle computing device according to another embodiment of the present invention is integrated into a central control unit. FIG. 35 is an internal configuration diagram of a driving control unit (33) of a zone control unit according to another embodiment of the present invention. FIG. 36 is an internal block diagram of a driving signal generator (34) according to a comparative embodiment of the present invention. FIG. 37 is an internal block diagram of a driving signal generator (35) according to one embodiment of the present invention. FIG. 38 is a diagram showing the signal flow in a zone control system (36) having a data security and backup path according to another embodiment of the present invention. FIG. 39 is a block diagram of a zone control unit (37) constituting the zone control system (36) of FIG. 38 according to another embodiment of the present invention. FIG. 40 is a configuration diagram of a vehicle control system (38) which is another embodiment of the present invention. FIG. 41a and FIG. 41b are drawings showing a frame (3900) generated by a vehicle control system to directly control an actuator according to one embodiment of the present invention. FIGS. 42 and FIGS. 43 are flowcharts of a vehicle control system according to one embodiment of the present invention controlling an actuator using a frame (3900). Specific details for implementing the invention

[0046] The present invention is capable of various modifications and may have various embodiments; specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and it should be understood that it includes all modifications, equivalents, and substitutions that fall within the technical spirit and scope of the present invention. In describing the present invention, detailed descriptions of related prior art are omitted if it is determined that such detailed descriptions may obscure the essence of the present invention.

[0047] Terms such as "first," "second," etc., may be used to describe various components, but the components are not limited by these terms. The terms may be used solely for the purpose of distinguishing one component from another.

[0048] The terms used in this invention are used merely to describe specific embodiments and are not intended to limit the invention. While the terms used in this invention have been selected to be as widely used as possible in consideration of their functions within the invention, they may vary depending on the intent of those skilled in the art, case law, or the emergence of new technologies. Furthermore, in specific cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in detail in the relevant description of the invention. Therefore, the terms used in this invention should be defined not merely by their names, but based on their meanings and the overall content of the invention.

[0049] A singular expression may include a plural expression unless the context clearly indicates otherwise. In the present invention, terms such as "comprising" or "having" are intended to specify the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0050] A Domain in this specification may refer to an area that integrates and manages a group of systems for specific functions within a vehicle. The Chassis Domain may include all control systems related to steering, braking, safety, wheels and vehicle driving performance, stability, ride comfort, etc. The Powertrain Domain may include all control systems related to propulsion, such as the engine, transmission, and battery management system. The Body Domain may include systems that control the vehicle's appearance and convenience functions, such as lighting, door locking, and window control. The Infotainment Domain may include systems that provide information and entertainment to occupants, such as audio, video, navigation, internet connectivity, and displays. Additionally, the ADAS / Autonomous Driving Domain may include systems that govern advanced driver assistance systems and autonomous driving technologies.

[0051] In this specification, "Zone" refers to a specific physical zone or region within a vehicle, and a "Zone Control System" may include a system for individually controlling and managing a specific physical zone or region within a vehicle.

[0052] The zone architecture network of the present specification may include a communication infrastructure designed to efficiently communicate data between various zones within a vehicle and to control systems within each zone.

[0053] A Zone Control Unit or Zone Control Apparatus as described herein may include a device that independently manages and controls devices within a specific physical area or zone within a vehicle. A Zone Control Unit may include an MCU subsystem and a network subsystem. A Zone Control Unit may further include at least one of an I / O subsystem, a memory subsystem, and a drive control unit.

[0054] Devices in a vehicle according to the present specification may include headlights, air conditioning controllers, side mirrors, seats, mood lamps, power windows, door locks, soft closing, trunk door locks, power trunks, taillights, wipers, rear curtains, washers, wireless charging, telescopic, sunroofs, steering, etc.

[0055] The user manipulation unit described in this specification may include a door lock, window, mirror operation switch, touch panel in the cluster, accelerator pedal, brake pedal, steering wheel, and user remote device installed in the interior of the vehicle.

[0056] As set forth in this specification, a vehicle control system refers to a set of electronic and mechanical systems that manage and control various functions and operations within a vehicle. A vehicle control system may include a central control unit and a plurality of zone control units connected via a communication network. A vehicle control system may further include at least one electronic control unit (ECU). A vehicle control system may further include at least one sensor and at least one actuator.

[0057] The vehicle control apparatus described herein may have at least one function among communication, routing, switching, computation, and driving signal generation. The vehicle control apparatus may include a central control unit and a plurality of zone control units. The vehicle control apparatus may further include at least one electronic control unit (ECU). The vehicle control apparatus may further include a driving control unit.

[0058] The Micro Control Unit subsystem described herein is a component of a vehicle control device that executes a specific program for a specific input to generate a result. The MCU subsystem may include a plurality of computing units. The MCU subsystem may further include a dedicated bus system, etc.

[0059] The memory subsystem described herein is a component of a vehicle control unit that manages data storage and access. The memory subsystem may include a Direct Memory Access (DMA) controller and various types of memory. The memory subsystem may further include at least one of a Deep Packet Inspection (DPI) module and a dedicated bus system.

[0060] The CPU subsystem described herein is a component of a vehicle control unit responsible for implementing user applications of a vehicle. The CPU subsystem may include a plurality of high-performance processors (e.g., ARM’s Cortex-A65AE). The CPU subsystem may further include a dedicated bus system.

[0061] The network subsystem described herein is a component of a vehicle control unit that controls data flow within the vehicle control unit and between the vehicle control units. The network subsystem may include a routing / switching module. The network subsystem may further include an Ethernet / CAN / LIN communication module. The network subsystem may further include a protocol conversion module. The network subsystem may further include a parsing unit that extracts specific data from packets or frames.

[0062] The driving signal processing unit described herein is a component of a vehicle control device that generates a signal for driving using command data transmitted from a network subsystem or a processing result value for driving. The driving signal processing unit may include an input / output subsystem and a driving control unit.

[0063] The input / output subsystem described herein may convert input data into a serial communication protocol and transmit it to a drive control unit. The input / output subsystem may include a plurality of communication controllers (e.g., serial communication controllers).

[0064] The drive control unit described herein is a component of a vehicle control unit that generates a drive signal (e.g., a PWM signal). The drive control unit may include a register and a register interface. The drive control unit may further include a pulse signal generation module. The drive control unit may further include a clock interface.

[0065] The network apparatus described in this specification is a component of a vehicle control device that integrates and performs the functions of a network subsystem and a driving signal processing unit.

[0066] The Network On Chip (NoC) bus system described herein is a bus system designed to efficiently handle communication between various components (e.g., core or processor core, memory module or memory subsystem, peripheral device, etc.) within a System-on-Chip (SoC).

[0067] A node in this specification may include a vehicle control unit (central control unit, zone control unit, electronic control unit (ECU)) connected to a network subsystem and a driving signal processing unit within the vehicle control unit.

[0068] A packet in this specification is a transmission unit delivered by an L3 switch, router, etc., when transmitted through a vehicle network at the Network Layer.

[0069] A frame in this specification is a unit transmitted at the data link layer, and a transmission frame may include information such as a checksum for error checking, the addresses of the sending and receiving hosts, and control codes used in other protocols, in addition to the transmission data sent from the upper layer.

[0070] A command signal in this specification represents a signal received from a user control unit, a sensor, or a domain system for operating a device within a vehicle, command data represents a target operation and target state of a device within a vehicle indicated by the command signal, and a driving operation result value may include control parameter values ​​(e.g., amplitude, period, width, etc. of a PWM signal) that calculate the polarity and output amount of a driving signal to achieve the target operation and target state of a device within a vehicle included in the command data, and determine the form of a driving signal (e.g., PWM) corresponding to the calculated polarity and output amount.

[0071] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In describing with reference to the accompanying drawings, identical or corresponding components are given the same reference numerals, and redundant descriptions thereof will be omitted.

[0072] FIG. 1a is a configuration diagram of a vehicle network (1) capable of controlling multiple zones within a vehicle.

[0073] The vehicle network (1) illustrated in FIG. 1a may include a central control unit (100) and first to fourth zone control units (110, 120, 130, 140). The first zone control unit (110) communicates with and can directly control the central control unit (100), adjacent zone control units (120, 140), and at least one electronic control unit (ECU) (111), at least one sensor (112), and at least one actuator (113) located in the first zone assigned to it. The second to fourth zone control units (120, 130, 140) also perform the same functions as the first zone control unit (110).

[0074] As illustrated in FIG. 1a, one central control unit (100) and four zone control units (110, 120, 130, 140) are shown, but this is merely one embodiment and the zone control units are not limited to four and can be implemented with a number other than four. The central control unit (100) may include an interface (not shown) for external diagnosis, firmware update, and OTA (Over-The-Air) communication with the outside. Additionally, the central control unit (100) may be connected to chassis, powertrain, and body domain controllers to receive respective domain control commands, and may transmit the received control commands to a zone control unit including a target device or broadcast them to an adjacent zone control unit.

[0075] The central control unit (100), zone control units (110, 120, 130, 140), electronic control units (ECUs) (111, 121, 131, 141), and sensors (112, 122, 132, 142) can receive control command signals for in-vehicle devices from in-vehicle switches, in-vehicle HMIs (Human-Machine Interfaces), or remote devices. The electronic control units (ECUs) (111, 121, 131, 141) connected to the zone control units (110, 120, 130, 140) can control in-vehicle devices in response to the control command signals. Each zone control unit (110, 120, 130, 140) can control a device within a vehicle by analyzing a message obtained through communication with a central control unit (100) and an adjacent zone control unit and transmitting a signal having a different form and information to an electronic control unit (ECU) or actuator connected to it.

[0076] As illustrated in FIG. 1a, the first to fourth zone control units (110, 120, 130, 140) can be connected in a ring topology network structure, and the first to fourth zone control units (110, 120, 130, 140) and the central control unit (100) can be connected in a star topology network structure. Accordingly, the communication path between the first to fourth zone control units (110, 120, 130, 140) and the central control unit (100) has a hardware backup path, thereby enabling uninterrupted communication.

[0077] Each zone control unit (110, 120, 130, 140) may include a network switch and may transmit packets received from a central control unit (100) and an adjacent zone control unit to a first contact node containing a target in-vehicle device intended by the packet. Here, the first contact node may be a central control unit (100) or a zone control unit (110, 120, 130, 140) or an electronic control unit (ECU) (111, 121, 131, 141) that is connected to the unit that first received the command signal (e.g., central control unit, zone control unit, electronic control unit (ECU), sensor) and includes a target device included in the command signal downstream.

[0078] Since the devices connected to the network switches of each zone control unit (110, 120, 130, 140) are identified by network addresses, the network switches can direct traffic flow to maximize the security and efficiency of the network.

[0079] Communication between the central control unit (100) and the zone control units (110, 120, 130, 140) and between the zone control units (110, 120, 130, 140) can use Ethernet communication of different speeds. In particular, communication between the central control unit (100) and the zone control units (110, 120, 130, 140) can be implemented as a TSN (Time Sensitive Network) based backbone communication network. Communication between the zone control unit (110, 120, 130, 140), the electronic control unit (ECU) (111, 121, 131, 141), the sensor (112, 122, 132, 141), and the actuator (113, 123, 133, 143) can be implemented using low-speed Ethernet, CAN, LIN, and hard wires, etc.

[0080] In the following, in a vehicle zone architecture network capable of controlling multiple zones within a vehicle, sensors connected to a zone control unit may include autonomous vehicle sensors such as cameras, radar, or lidar that process large amounts of data, and collision detection sensors, lane departure detection sensors, ultrasonic sensors, parking assist sensors, speed sensors, acceleration sensors, GPS sensors, temperature sensors, humidity sensors, gas sensors, fine dust sensors, lighting sensors, etc. that process small amounts of data.

[0081] The vehicle network (1) illustrated in FIG. 1a satisfies the strict end-to-end low latency requirements often demanded in real-time and mission-oriented applications. Accordingly, it uses standard protocols such as Time Sensitive Network (TSN) to provide real-time guarantees such as limited latency, low packet delay variation, and low packet loss, and uses various mechanisms such as time synchronization between nodes, scheduling, and traffic shaping to ensure deterministic traffic delivery.

[0082] On the other hand, each Zone control unit (110, 120, 130, 140) may transmit a packet containing its own identifier and a copy of the packet in a first direction and a second direction, respectively, at regular time intervals. The first direction may be clockwise under a ring structure centered on the central control unit (100), and the second direction may be counterclockwise. Its own identifier may include its own device number, protocol type, a timestamp indicating the period during which the data was generated, and a check code to verify whether the data is corrupted.

[0083] The Zone control unit (110 to 140) can first check for data corruption if the received packet is not of itself or its downstream device, discard it if corruption exists, and determine whether the currently received message is duplicated with a previously received message if there is no corruption. If there is a duplicate, the currently received message is discarded, and if there is no duplicate, the current message can be retransmitted in the first direction and the second direction. Through this, a backup communication network can be established in which data is reliably transmitted to the target device even if an error occurs in communication between specific Zone control units.

[0084] FIG. 1b is an internal block diagram of a zone control unit (150) constituting a vehicle control system (1-1) that controls a plurality of zones within a vehicle according to a comparative embodiment of the present invention.

[0085] The zone control unit (150) illustrated in FIG. 1b may include a high-performance CPU (HPC) (151) for managing electronic control units (ECUs) in a certain area of ​​the vehicle, a switch (152) for transmitting data input from the outside to a central control unit (160) or another zone control unit (170), and an MCU (153, 154) for controlling a sensor (155) and an actuator (155).

[0086] The zone control unit (150) of FIG. 1b is configured with an integrated chip for the HPC (151) and the switch (152), but the MCU (153, 154) may not be integrated.

[0087] In the zone control unit (150) of FIG. 1b, if a failure occurs in the MCU (154) that controls the actuator (156), the MCU (154) can transmit a signal indicating that a failure has occurred to the outside, but a problem arises in that it can no longer generate a signal to control the actuator (156). Therefore, although the failure signal can be detected externally and the system can be restored, the actuator (156) cannot operate until the time of restoration. Therefore, a control device is required that can control the actuator without interruption even when the MCU (154) fails, while integrating the MCU (154).

[0088] FIG. 2a is a schematic diagram of a vehicle control system (2-1) for a vehicle zone architecture network.

[0089] As illustrated in FIG. 2a, a vehicle control system (2-1) for a zone architecture network may include one central control unit (200), a plurality of zone control units (210, 220, 230, 240), and a plurality of electronic control units (250, 260, 270, 280). The vehicle control system (2-1) may further include a plurality of actuators (290). A plurality of actuators (290) drive a vehicle device (291), and a sensor (not shown) and a user input device (not shown) that receive a control command signal for the vehicle device (291) can be connected to at least one of a central control unit (200), a plurality of zone control units (210, 220, 230, 240), and a plurality of electronic control units (250, 260, 270, 280).

[0090] As shown in FIG. 2a, the vehicle control system (2-1) may require a central gateway (202) and an L2 / L3 switch (211, 221, 231, 241) in each zone control unit (210, 220, 230, 240) and a central control unit (200) to configure a zone architecture. Accordingly, in the vehicle control system (2-1), a plurality of computing devices (201, 202, 211, 212, 221, 222, 231, 232, 241, 242, 251, 261, 271, 281) may be respectively placed in the central control unit (200), zone control units (210, 220, 230, 240), and electronic control units (ECUs) (250, 260, 270, 280). The central computing device (201) of the central control unit (200) can control the data flow with the zone control units (210, 220, 230, 240) and an external system (not shown). Accordingly, the central computing unit (201) of the central control unit (200) and the computing unit within the central gateway (202) are high-performance processors, and the first computing unit (212, 222, 232, 242) within the zone control unit (210, 220, 230, 240) and the second computing unit (251, 262, 272, 282) within the electronic control unit (ECU) can be implemented as low-performance processors.

[0091] The signal transmitted directly by the zone control unit (210, 220, 230, 240) to the actuator it directly controls among the plurality of actuators (290_1 to 290_8) and the signal transmitted by the zone control unit (210, 220, 230, 240) to the electronic control unit (ECU) (290) may differ in the form of the signal and the information included. That is, the signal transmitted from the zone control unit (210, 220, 230, 240) to the electronic control unit (ECU) (250, 260, 270, 280) may be in the form of a packet or a frame based on CAN, LIN, or Ethernet. The packet or frame may include actuator command data (A) that includes an in-vehicle device that is the control target, a target operation, and a target state. On the other hand, the signal that the zone control unit (210, 220, 230, 240) directly transmits to the actuator (290) that it directly controls may be an actuator driving signal (C), such as a pulse signal (e.g., PWM (Pulse Width Modulation) signal).

[0092] The vehicle control system (2-1) for the zone architecture of FIG. 2a has a disadvantage that the time taken to reach actual operation from the time an actuator operation command is generated may be long due to multiple computation processing paths that a single actuator command data (A) must pass through (e.g., a path passing through computation devices 201 - 202 - 211 - 212 - 251).

[0093] FIG. 2b is a schematic diagram of a vehicle control system (2-2) for a vehicle's zone architecture network.

[0094] The electronic control unit (ECU) (250_1, 260_1, 270_1, 280_1) of the vehicle control system (2-2) shown in FIG. 2b differs from the electronic control unit (ECU) (250, 260, 270, 280) of FIG. 2a in that it lacks the computing device (251, 261, 271, 281) within the electronic control unit (ECU) (250, 260, 270, 280) of FIG. 2a.

[0095] The central control unit (200) transmits actuator command data (A) to the zone control units (210_1, 220_1, 230_1, 240_1), and the zone control units (210_1, 220_1, 230_1, 240_1) can calculate an actuator driving operation result value (B) using the actuator command data and transmit it to the electronic control unit (ECU) (250_1, 260_1, 270_1, 280_1). The electronic control unit (ECU) (250_1, 260_1, 270_1, 280_1) can generate an actuator driving signal (C) using the received actuator driving operation result value (B) and transmit it to the actuator (290). That is, the computational device (212_1, 222_1, 232_1, 242_1) that directly controls the actuator (290) is placed only in the zone control unit (210_1, 220_1, 230_1, 240_1).

[0096] The calculation result value (B) for actuator driving transmitted by the zone control unit (210_1, 220_1, 230_1, 240_1) to the electronic control unit (ECU) (250_1, 260_1, 270_1, 280_1) may be transmitted in the form of a packet or frame based on CAN, LIN, or Ethernet, and the calculation result value (B) for actuator driving may include control parameter values ​​that determine the form of the actuator driving signal (C). On the other hand, the signal directly transmitted from the zone control unit (210_1, 220_1, 230_1, 240_1) to the actuator (290) may include an actuator driving signal (C), such as a Pulse Width Modulation (PWM) signal.

[0097] The disadvantage of the vehicle control system (2-2) of FIG. 2b is that the computational units (212_1, 222_1, 232_1, 242_1) with complex functions are distributed among the zone control units (210, 220, 230, 240), and synchronization between the zone control units (210_1, 220_1, 230_1, 240_1) may be difficult. Accordingly, errors in the actuator driving signal (C) or variations in the time it takes to reach the actuator may occur.

[0098] FIG. 3 is a schematic diagram of a vehicle control system (2-3) for a vehicle zone architecture network according to one embodiment of the present invention.

[0099] The vehicle control system (2-3) of FIG. 3 shows that the functions of the zone control units (210, 220, 230, 240) and the computational units (212, 222, 232, 242, 251, 261, 271, 281) of the electronic control unit (ECU) (250, 260, 270, 280) of the vehicle control system (2-1) of FIG. 2a may be integrated into the central computational unit (201_1) of the central control unit (200_1). That is, a central computational unit (201_1) with a built-in high-capacity memory and high-performance processor may be placed in the central control unit (200_1) to control all actuators (290) inside the vehicle.

[0100] The central control unit (200_1) can directly transmit an actuator driving signal (C) generated using command data (A) received from the outside to the actuator (290).

[0101] The central control unit (200_1) can transmit the result of an operation (B) for driving an actuator, calculated using actuator command data (A) received from the outside, to the zone control units (210_2, 220_2, 230_2, 240_2).

[0102] The zone control unit (210_2, 220_2, 230_2, 240_2) can generate an actuator driving signal (C) using the received actuator driving calculation result value (B) and transmit it to an actuator directly connected to the zone control unit (210_2, 220_2, 230_2, 240_2) among a plurality of actuators (290). Additionally, the zone control unit (210_2, 220_2, 230_2, 240_2) can transmit the received actuator driving calculation result value (B) to an electronic control unit (ECU) (250_1, 260_1, 270_1, 280_1).

[0103] The electronic control unit (ECU) (250_2, 260_2, 270_2, 280_2) can generate an actuator driving signal (C) using the received actuator driving calculation result value (B) and transmit it to an actuator directly connected to the electronic control unit (ECU) (250_2, 260_2, 270_2, 280_2) among the plurality of actuators (290).

[0104] The advantage of the vehicle control system (2-3) of Fig. 3 is that precise synchronization between the zone control units (210_2, 220_2, 230_2, 240_2) is possible, so the transmission delay time for each actuator is constant. However, the vehicle control system (2-3) of Fig. 3 has the disadvantage that if an error occurs in the central computing unit (201_1) of the central control unit (200_1), the function of the entire vehicle control system (2-3) may be interrupted.

[0105] FIG. 4 is a schematic diagram of a vehicle control system (2-4) according to another embodiment of the present invention.

[0106] In the vehicle control system (2-4) illustrated in FIG. 4, a central computing unit (201_2) that controls all devices inside the vehicle may be placed in a central control unit (200_2). Here, all devices inside the vehicle may include actuators, autonomous driving control devices, driving assistance devices, braking control devices, and driving path control devices.

[0107] In the case of normal operation, the central computing unit (201_2) can broadcast to the zone control units (210_3, 220_3, 230_3, 240_3) a calculation result value (B) for actuator driving calculated using actuator command data (A) which includes a target operation or target state (operation direction, operation holding time, etc.) for a target vehicle device input from the outside. Here, the calculation result value (B) for actuator driving may include control parameters of an actuator driving signal (C) for achieving the target operation or target state of the target vehicle device included in the actuator command data (A), and the actuator driving signal (C) may include a pulse signal. The control parameters may include at least one of a prescale value, a counter value, a comparison value, a clock distribution value, a signal period, a signal pattern, and a signal amplitude.

[0108] The L2 / L3 switches (211, 221, 231, 241) of the zone control unit (210_3, 220_3, 230_3, 240_3) select an actuator driving calculation result value (B) that drives an in-vehicle device directly connected to itself among the actuator driving calculation result values ​​(B) transmitted from the central control unit (200_2), transmit it to the first driving signal generator (213, 223, 233, 243), and the first driving signal generator (213, 223, 233, 243) can generate an actuator driving signal (C) using the selected actuator driving calculation result value (B) and transmit it to the actuator (290). Additionally, the zone control unit (210_3, 220_3, 230_3, 240_3) can select a calculation result value (B) for driving an actuator that drives an in-vehicle device connected to an electronic control unit (ECU) connected to itself and transmit it to an electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3) connected to itself.

[0109] The electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3) can generate an actuator driving signal (C) using the actuator driving calculation result value (B) transmitted by the zone control unit (210_3, 220_3, 230_3, 240_3) and transmit it to the actuator (290) connected to it.

[0110] The zone control unit (210_3, 220_3, 230_3, 240_3) may further include a first hidden calculation unit (212_3, 222_3, 232_3, 242_3). The first hidden calculation unit (212_3, 222_3, 232_3, 242_3) can produce an actuator driving calculation result value (B) identical to that produced by the central calculation unit (201_2) for the same actuator command data (A).

[0111] In the vehicle control system (2-4) of FIG. 4, when the central computing unit (201_2) is operating normally, the first hidden computing unit (212_3, 222_3, 232_3, 242_3) of the zone control unit (210_3, 220_3, 230_3, 240_3) and the second hidden unit (251_3, 261_3, 271_3, 281_3) of the electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3) may be deactivated.

[0112] A monitoring device (e.g., a lockstep structure) within the central computing unit (201_2) detects an operation error in the central computing unit (201_2), and when an error occurs in the central computing unit (201_2), the central gateway (202) of the central control unit (200_2) and the L2 / L3 switches (211, 221, 231, 241) of the zone control units (210_3, 220_3, 230_3, 240_3) can transmit actuator command data (A) input to the central control unit (200_2) after detecting the error in the central computing unit (201_2) to the zone control units (210_3, 220_3, 230_3, 240_3).

[0113] The electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3) transmits the actuator command data (A) that drives a device directly connected to itself among the received actuator command data (A) to the first hidden operation unit (212_3, 222_3, 232_3, 242_3), and the first hidden operation unit (212_3, 222_3, 232_3, 242_3) can calculate an operation result value (B) for driving the actuator using the received actuator command data (A) and transmit it to the register interface (3510 of FIG. 35) of the first driving signal generator (213, 223, 233, 243).

[0114] The first driving signal generator (213, 223, 233, 243) can generate an actuator driving signal (C) according to the actuator driving calculation result value (B) and its own clock signal transmitted by the first hidden calculation device (212_3, 222_3, 232_3, 242_3).

[0115] The L2 switches (211, 221, 231, 241) of the Zone control units (210_3, 220_3, 230_3, 240_3) transmit the actuator command data (A) corresponding to the in-vehicle device connected to the electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3) among the received actuator command data (A) to the electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3), and the second hidden computing device (251_3, 261_3, 271_3, 281_3) of the electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3) receives The result of an operation for driving an actuator (B) calculated using actuator command data (A) can be transmitted to the register interface (3510 in FIG. 37) of the second driving signal generator (252, 262, 272, 282).

[0116] The second driving signal generator (252, 262, 272, 282) can generate an actuator driving signal (C) according to the actuator driving calculation result value (B) and clock signal transmitted by the second hidden calculation device (251_3, 261_3, 271_3, 281_3). Meanwhile, if an error is detected in the second hidden calculation device (251_3, 261_3, 271_3, 281_3), the first hidden calculation device (212_3, 222_3, 232_3, 242_3) or L2 switch (211, 221, 231, 241) of the Zone control unit (210_3, 220_3, 230_3, 240_3) receives the calculation result value (B) for actuator driving calculated by the first hidden calculation device (212_3, 222_3, 232_3, 242_3) from the second driving signal generator (252, 262, 272) of the electronic control unit (ECU) (250_3, 260_3, 270_3, 280_3). It can be transmitted to the register interface (3510 in Fig. 37) of 282).

[0117] When the register interface and register (3510 and 3520 in FIG. 37) of the second driving signal generator (252, 262, 272, 282) receive a direct control signal (DCS) transmitted by the central arithmetic unit (201_2), the first hidden arithmetic unit (212_3, 222_3, 232_3, 242_3), or the second hidden arithmetic unit (251_3, 261_3, 271_3, 281_3), the input operation result value (B) for actuator driving is directly transmitted to the pulse signal generation module (see 3540 and 3550 in FIG. 37) within the second driving signal generator (252, 262, 272, 282).

[0118] When the register interface and register (3510 and 3520 in FIG. 37) of the second driving signal generator (252, 262, 272, 282) receive a write control signal (WS) transmitted by the central arithmetic unit (201_2), the first hidden arithmetic unit (212_3, 222_3, 232_3, 242_3), or the second hidden arithmetic unit (251_3, 261_3, 271_3, 281_3), the input operation result value (B) for driving the actuator can be written to a specific address of the register (see 3520 in FIG. 37).

[0119] The direct control signal (DCS) input to the register interface (see 3510 in FIG. 37) is input from a higher system (e.g., central arithmetic unit, arithmetic unit of a zone control unit) when driving an urgent device, and the write signal may be input when driving a less urgent device. That is, the pulse signal generation module (see 3540, 3550 in FIG. 37) can finally output an actuator driving signal (C) by directly using the configuration value or the actuator driving operation result value (B) stored in the register (3520) or the actuator driving operation result value (B) transmitted from the central arithmetic unit (201_2), the first hidden arithmetic unit (212_3, 222_3, 232_3, 242_3) or the second hidden arithmetic unit (251_3, 261_3, 271_3, 281_3).

[0120] Additionally, when an error is detected in the operation result value (B) for driving the actuator transmitted from the central operation unit (201_2), the first hidden operation unit (212_3, 222_3, 232_3, 242_3), or the second hidden operation unit (251_3, 261_3, 271_3, 281_3), or when the state of the target device exceeds a limit value (i.e., when the register receives an error signal (AF) from the actuator), the register (3520) transmits a safety control parameter stored at a specific address to the pulse signal generation module (see 3540, 3550 in FIG. 37), and the safety control parameter may be an actuator control parameter that causes the device to stop or decelerate.

[0121] The vehicle control system (2-4) of FIG. 4 may include a signal tunneling module (not shown) that transmits a calculation result value (B) for actuator driving calculated by a central control unit (200_2) or a zone control unit (210_3, 220_3, 230_3, 240_3) to first and second pulse signal generating modules (3540 and 3550) within a first driving signal generator (213, 223, 233, 243) and a second driving signal generator (252, 262, 272, 282) connected to a target device. The signal tunneling module may include a network stack and a register interface and registers (see 3510 and 3520 in FIG. 37) within a first driving signal generator (213, 223, 233, 243) and a second driving signal generator (252, 262, 272, 282). The network stack may include a routing device (see 16 in FIG. 18) of a central gateway (202), a communication interface, and L2 switches (211, 222, 232, 242) and a communication interface of a zone control unit (210_3, 220_3, 230_3, 240_3).

[0122] The vehicle control system (2-4) of FIG. 4 uses the first hidden computing device (212_3, 222_3, 232_3, 242_3) and the second hidden computing device (251_3, 261_3, 271_3, 281_3) to enable continuous, uninterrupted control of the device (291) in the vehicle even if an error occurs in the central computing device (201_2) of the central control unit (200_2).

[0123] FIG. 5 is a diagram showing the signal flow of a vehicle control system (3) according to another embodiment of the present invention.

[0124] The command data generation unit (310) and driving signal processing unit (320) illustrated in FIG. 5 may be included in the central control unit (100), zone control unit (110, 120, 130, 140), and electronic control unit (ECU) (111, 121, 131, 141) of FIG. 5. Additionally, the actuator unit (330) illustrated in FIG. 5 may include a zone actuator (331) that drives doors, seats, lights, mirrors, etc., arranged by zone, and a domain actuator (332) that controls in-vehicle devices in driving, braking, and steering domains. The sensor unit (320) may include sensors such as cameras, radar, and lidar.

[0125] The command signal (350) may be generated from a vehicle switch (301) within the user control unit (300), a cluster touch panel (302), a remote device (303), a pedal (304), or a steering wheel (305), or may be generated from an Advanced Driver Assistance System (ADAS) or an autonomous driving system. Subsequently, command data (360) is generated in a Command Data Generation Unit (310) (e.g., included in a central control unit, a zone control unit, or an electronic control unit (ECU)), and the command data (360) is then calculated and interpreted in a Driver Signal Handler (320) to generate a driving signal (370), which can then be transmitted to an actuator unit (330).

[0126] The first command data generation unit (311) of the command data generation unit (310) can identify command signals (350) (e.g., switch type, switch direction, switch activation time, etc.) input from a switch (301) inside the vehicle, a touch panel (302) of the cluster, and a remote device (303) to generate command data (360) indicating the target operation and target state of the target device inside the vehicle.

[0127] The second command data generation unit (312) of the command data generation unit (310) is connected to the sensor unit (320), and the sensor unit (320) can detect the direction of operation, position status, and surrounding conditions of the accelerator pedal, brake pedal, and steering wheel inside the vehicle, as well as windows, doors, and the surrounding conditions of the vehicle.

[0128] The command data generation unit (310) can finally determine a target operation (e.g., actuator driving speed, braking magnitude, driving path, etc.) by referring to the outputs of the first command data generation unit (311) and the second command data generation unit (312) and transmit it to the driving signal processing unit (320).

[0129] The command data generation unit (310) may include a plurality of computational devices and communication interfaces.

[0130] The first to fourth driving signal processing units (321, 322, 323, 324) of the driving signal processing unit (320) may include a calculation device (not shown) that calculates the polarity and output amount of a driving signal (370) for achieving the target operation and target state of a target device included in the first and second command data (360, 361) transmitted from the first and second command data generation units (311, 312), and calculates a control parameter value (e.g., amplitude, period, width, etc. of a PWM signal, etc.) corresponding to the calculated polarity and output amount.

[0131] FIG. 6 is a schematic diagram of a vehicle control system (4) capable of controlling a plurality of zones within a vehicle according to another embodiment of the present invention.

[0132] The vehicle control system (4) illustrated in FIG. 6 may include one central control unit (400) and a plurality of zone control units (410, 420, 430, 440). The one central control unit (400) and the plurality of zone control units (410, 420, 430, 440) may drive a plurality of electronic control units (ECUs) (411, 412, 421, 431, 441) and a plurality of safety devices (413, 422, 442, 432).

[0133] A plurality of safety devices (413, 422, 442, 432) may include actuators that drive in-vehicle devices important for safety during vehicle operation. In this specification, such actuators and devices are collectively defined as safety devices. Safety devices may include, for example, actuators that drive brakes or actuators that drive steering devices.

[0134] The vehicle control system (4) illustrated in FIG. 6 can ensure seamless control of the first safety device (413) by providing multiple control paths, rather than just one, for controlling the first safety device (413) in the first zone.

[0135] One of a plurality of paths may be determined according to at least one of the location, type, and identifier of the unit (e.g., central control unit, zone control unit, or electronic control unit (ECU)) to which the user control unit (UC1, UC2, UC3, UC4) that generates a command signal for an in-vehicle device is connected. That is, when the central control unit (400) receives a command signal for the first safety device (413) from the first user operation unit (UC1), the control path for the first safety device (413) may include ABC path, AD path, EF path, and G path; when the first zone control unit (410) receives a command signal for the first safety device (413) from the second user operation unit (UC2), the control path for the first safety device (413) may be BC path, D path, and AEF path; and when the fifth electronic control unit (ECU) (401) receives a command signal for the first safety device (413) from the third user operation unit (UC3), the control path for the first safety device (413) may include F path, EG path, EABC path, and EAD path.

[0136] Meanwhile, the vehicle control system (4) can update a plurality of paths that transmit command signals to the first safety device (413) in real time or periodically. That is, the updated control paths can be determined by the location and type of the unit receiving the command signal to the device and the reliability of each path (e.g., paths with short signal delay, paths with low signal congestion, paths with high transmission bandwidth).

[0137] Additionally, each of the central control unit (400), the plurality of zone control units (410, 420, 430, 440) and the plurality of electronic control units (ECUs) (411, 412, 421, 431, 441) of FIG. 6 may include a monitoring device (not shown) that monitors its own status, the control path connected to it, and the status of the safety device connected to it. The monitoring device can check in real time whether command data for the safety device has been received, determine whether its own operating status is normal, determine the reliability level for each control path connected to it, and check whether the status of the safety device is within a preset state range. If the operation result of the safety device confirmed by the monitoring device falls outside the preset state range corresponding to the device command data, the central control unit or the zone control unit may decide to transmit a signal for driving the safety device to at least one of the paths with a higher reliability level (e.g., a path with short signal delay, a path with low signal congestion, a path with a large transmission bandwidth) among the paths excluding the current path, according to a preset rule.

[0138] Additionally, the central control unit (300) can determine a new control path other than the path passing through the zone control unit or electronic control unit (ECU) where the error occurred.

[0139] Additionally, the zone control unit may include a signal converter (not shown), and the signal converter may include at least one of Ethernet-to-Ethernet protocol conversion, CAN-CAN protocol conversion, LIN-LIN protocol conversion, CAN-LIN protocol conversion, Ethernet-CAN protocol conversion, Ethernet-LIN protocol conversion, Ethernet-serial communication signal conversion, CAN-serial communication signal conversion, and LIN-serial communication signal conversion.That is, Ethernet-to-Ethernet protocol conversion is used when the first zone control unit (410) communicates with the central control unit (400) and adjacent zone control units (420, 430), and Ethernet-CAN and Ethernet-LIN protocol conversion can be used in a path (ABC path) in which the first zone control unit (410) receives a signal (e.g., device command data or calculation result value for device operation) from the central control unit (400) and transmits it to the first safety device (413) through the first-2 electronic control unit (ECU) (412), and CAN-CAN protocol conversion, LIN-LIN protocol conversion, and CAN-LIN protocol conversion receive a command signal for the first safety device (413) from the fourth user operation unit (UC4) connected to the first-1 electronic control unit (ECU) (411), transmit it to the first zone control unit, and the first zone control The unit (410) is used in a path (HBC) to transmit the command signal to the first-second electronic control unit (ECU) (412) connected to the first safety device (413), and the signal conversion between Ethernet communication and serial communication can be used in a path (ID, JD) in which the first zone control unit (410) receives a command signal from an adjacent zone control unit (420, 430) or a central control unit (400) and transmits it directly to the first safety device (413), and the signal conversion between CAN communication and serial communication and the signal conversion between LIN communication and serial communication can be used in a path (HD) in which the first zone control unit (410) receives a command signal from the first-first electronic control unit (ECU) (411) and transmits it directly to the first safety device (413). That is, the procedure for protocol conversion of the signal converter of the zone control unit can be determined according to the unit to which the command signal for the device is input and the transmission path of the command signal.

[0140] In FIG. 6, if an error occurs in an electronic control unit (ECU) or zone control unit connected to the first to fourth safety devices (413, 422, 432, 441), the central control unit (400) can determine a new path other than the path passing through the electronic control unit (ECU) or zone control unit where the error occurred and transmit data.

[0141] The central control unit (400), zone control unit (410, 420, 430, 440) and electronic control unit (ECU) (411, 412, 421, 431, 441) illustrated in FIG. 6 can receive command signals generated from user operation units (UC1, UC2, UC3, UC4) or sensors (not shown).

[0142] The central control unit (400), zone control unit (410, 420, 430, 440), and electronic control unit (ECU) (411, 412, 421, 431, 441) illustrated in FIG. 6 generate at least one of command data, a driving operation result value, and a driving signal corresponding to a command signal for a specific actuator (not shown) that controls a safety device (413, 422, 432, 442) among command signals received from a user operating unit (UC1, UC2, UC3, UC4) or a sensor (not shown), and directly control the specific actuator through a plurality of control paths. The central control unit (400), zone control unit (410, 420, 430, 440), and electronic control unit (ECU) (411, 412, 421, 431, 441) generate command data and driving operation results. At least one of the result value and the driving signal can be transmitted.

[0143] FIG. 7 is a block diagram showing a partial internal configuration of a vehicle control system (5) according to another embodiment of the present invention.

[0144] As illustrated in FIG. 7, the vehicle control system (5) controlling the safety actuator illustrated in FIG. 6 may include a central control unit (500), a zone control unit (530), and an electronic control unit (ECU) (560), each of which may be connected to the safety actuator (55). Each of the central control unit (500), the zone control unit (530), and the electronic control unit (ECU) (560) may be connected to user operation parts (UC1 to UC3) for the safety actuator (550).

[0145] The central control unit (500) may include a CPU subsystem (501) composed of a plurality of computing devices (502), a first MCU subsystem (503) composed of a plurality of computing devices (504) for performing a specific operation program, a first network subsystem (505) that receives at least one of actuator command signals from the first to third user operation units (UC1 to UC3) and transmits it to the second network subsystem (531) of the zone control unit (530) or the communication module (561) of the electronic control unit (ECU), and a first memory subsystem (506) that stores programs and temporarily stores data.

[0146] The zone control unit (530) may include a second MCU subsystem (532) composed of a plurality of computing devices (533) that perform a specific operation program, a second network subsystem (531) that receives at least one of the command signals of the first to third user operation units (UC1 to UC3) and transmits it to the first network subsystem (505) of the central control unit (500) or the communication module (561) of the electronic control unit (ECU) (560), and a second memory subsystem (534) that stores the program and temporarily stores data.

[0147] The electronic control unit (ECU) (560) may include a communication module (561) including a communication interface and a communication controller (not shown), a third MCU subsystem (562) that calculates a calculation result value for driving an actuator using actuator command data and generates a signal for driving an actuator, and a third memory subsystem (564) that stores a program and temporarily stores data. Meanwhile, the first MCU subsystem (503), the second MCU subsystem (532), and the third MCU subsystem (562) may generate the same actuator driving signal for the same command data.

[0148] When the first network subsystem (505) of the central control unit (500) identifies from the input command data that the target device corresponds to the safety actuator (550) connected to it, at least one computing unit within the first MCU subsystem (503) can generate a driving signal using the received command data or the driving computation result value and transmit it to the safety actuator (550).

[0149] When the second network subsystem (531) of the zone control unit (530) identifies that the target device corresponds to the safety actuator (550) connected to it based on the input command data or the result of the operation for driving, at least one operation unit within the second MCU subsystem (532) can generate a driving signal using the received command data or the result of the operation for driving and transmit it to the safety actuator (550).

[0150] The electronic control unit (ECU) (560) can use command data or driving calculation result values ​​received through the communication module (561) to allow the seventh calculation device (563) of the third MCU subsystem (562) to calculate driving calculation result values ​​and generate driving signals and transmit them to the safety actuator (550) connected to it.

[0151] The first and second network subsystems (505, 531) may include a communication interface, routing, switching, and a packet processing engine, and the packet processing engine may include a protocol conversion function between heterogeneous packets. Additionally, the first to third MCU subsystems (503, 532, 562), the first and second network subsystems (505, 531), and the communication module (561) can monitor whether a command signal for the safety actuator (550) has been received, the transmission path of the command signal, and the reliability, and can monitor the operation result of the safety actuator (550) corresponding to the command data in real time through a sensor installed on the safety actuator (550).

[0152] If the result of the operation of the safety actuator (550) differs from the state predicted in advance from the command data (e.g., the target state is outside the allowable range), the first to third MCU subsystems (503, 532, 562) or the first and second network subsystems (505, 531) may decide to transmit a driving signal for the safety actuator (550) to the most reliable path, excluding the existing signal transmission path, that is, another path determined according to a predetermined rule based on arrival time, packet congestion, transmission speed, and bandwidth.

[0153] FIG. 8 is a block diagram of a system (6) for controlling a device inside a vehicle according to a comparative embodiment of the present invention.

[0154] The system (6) for controlling the in-vehicle device illustrated in FIG. 8 may include a zone control unit (600, 620), a central control unit (630), and an electronic control unit (ECU). The system (6) for controlling the in-vehicle device may further include an actuator (640).

[0155] The zone control unit (600, 620) may include an MCU subsystem (601), a network subsystem (503), and a memory (604).

[0156] The network subsystem (603) can interpret and analyze sensor information, update information, user operation information, etc., input from the electronic control unit (ECU) (610) in the vehicle, the adjacent zone control unit (620), and the central control unit (630), identify the type and kind of information, and determine whether to consume the input information internally or retransmit it externally.

[0157] The MCU subsystem (601) may include a plurality of cores (602), at least one of which may be assigned to direct driving of the actuator (640).

[0158] The power, clock, and ground of the MCU subsystem (601) and the network subsystem (603) are independent of each other, so that even if an error occurs in the MCU subsystem (601), the communication and switching functions of the network subsystem (603) are maintained, thereby maintaining the continuity of the data flow. However, if a problem occurs with the power and clock input to the MCU subsystem (601), control of the actuator (640) driving the device in the vehicle is cut off, which may cause a serious accident involving the driver.

[0159] FIGS. 9a and 9b are block diagrams of a device (7-1, 7-2) for controlling a device inside a vehicle according to one embodiment of the present invention.

[0160] The system (7-1) controlling the in-vehicle device illustrated in FIG. 9a may include a zone control unit (700-1, 730-1), an MCU subsystem (701-1), a network subsystem (703-1), an input / output subsystem (705-1), and a drive control unit (707-1). That is, the drive control unit (707-1) may be configured as one of the input / output devices managed by the input / output subsystem (705-1). The power and clock of each of the MCU subsystem (701-1), network subsystem (703-1), and drive control unit (707-1) are configured independently of each other, so that even if the fourth core (702-1) of the MCU subsystem (701-1) fails to operate or the sixth core (708-1) of the drive control unit (707-1) fails to operate, control of the actuator (750-1) can be maintained seamlessly through the mutual complementary functions of the fourth core (702-1) and the sixth core (708-1). That is, in the event of an error in the fourth core (702-1), the sixth core (708-1) can calculate a driving operation result value using command data and transmit it to the driving signal generation module (709-1).

[0161] The drive control unit (707-1) illustrated in FIG. 9a may largely include a sixth core (708-1), a drive signal generation module (709-1), and a communication module (711-1). The sixth core (708-1) interprets actuator command data to calculate a calculation result value for driving the actuator and performs a write operation on a register (not shown) of the drive signal generation module (709-1). The drive signal generation module (709-1) can generate a signal for driving the actuator using the calculation result value for driving the actuator stored in the register.

[0162] An input / output subsystem (705-1) connected to a drive control unit (707-1) may include a plurality of communication controllers and GPIO multiplexers (see FIG. 21 and FIG. 22), and the plurality of communication controllers may convert packet-type or frame-type signals transmitted from a network subsystem (703-1) into serial communication types and transmit them to the drive control unit (707-1). Additionally, the communication module (711-1) of the drive control unit (707-1) may include a communication interface, Ethernet, CAN, and LIN communication controllers, and may be connected to an external communication device including an electronic control unit (ECU).

[0163] If the same third-party semiconductor design IP (intellectual property) or system architecture used in the fourth core (702-1) and the sixth core (708-1) of FIG. 9a is used to implement the functional purpose of the present invention, it may result in increased costs due to the use of high-cost semiconductor design IP (intellectual property) and excessive specifications and software complexity, as well as a significant development period. Therefore, the sixth core (708-1) may be implemented to apply a lower-performance processor and system architecture compared to the fourth core (702-1).

[0164] The first register (708-2) within the drive control unit (707-2) illustrated in FIG. 9b can store an actuator driving operation result value calculated by interpreting actuator command data transmitted from the input / output subsystem (705-2) in the sixth core (708-1) of FIG. 9a. If an error occurs in the sixth core (708-1) of FIG. 9a or an error occurs in writing the first register (708-2), the drive control unit (707-2) can detect this and transmit it to the MCU subsystem (701-2) via the input / output subsystem (705-2) or the NoC bus system (706-2). After that, at least one arithmetic unit (702-2) of the MCU subsystem (701-2) can fetch actuator command data input from the network subsystem (703-2), generate a control parameter value for the actuator driving signal, i.e., an actuator driving calculation result value, and transmit it to the driving control unit (707-2) through the NoC bus system (706-2) and the input / output subsystem (705-2).

[0165] The second register (709-2) of the drive control unit (707-2) writes the result of an operation for driving an actuator transmitted by at least one arithmetic unit (702-2) of the MCU subsystem (701-2) to a specific address, and the drive signal generation module (712-2) can generate a signal for driving an actuator using the value written to the specific address of the second register (709-2) and transmit it to the actuator (705-2).

[0166] The input / output subsystem (705-2) of FIG. 9b can perform signal conversion from an Ethernet protocol, a CAN protocol, or a LIN protocol to a serial communication protocol between the network subsystem (703-2) and the drive control unit (707-2). Alternatively, the network subsystem (703-2) can parse an actuator command signal or a driving operation result value from a packet or frame of Ethernet, CAN, or LIN and transmit it to the input / output subsystem (705-2), and the input / output subsystem (705-2) can convert the received actuator command signal or driving operation result value into serial communication and transmit it to the drive control unit (707-2).

[0167] FIGS. 10a and 10b are schematic block diagrams of a vehicle control system (800) according to another embodiment of the present invention.

[0168] The vehicle control system (800) illustrated in FIGS. 10a and 10b may include a central control unit (830), a first zone control unit (810), an adjacent zone control unit (840), and an electronic control unit (ECU) (850). Each of the zone control units (810, 840) may include a network subsystem (811) and a driving signal processing unit (812).

[0169] The vehicle control system (800) can receive various command signals from a switch (A) inside the vehicle, an HMI (B) inside the vehicle, a remote device (C), a remote server (D), and a sensor (E). The node receiving the command signals can be at least one of a zone control unit (810, 840), a central control unit (830), and an electronic control unit (ECU) (850) placed inside the vehicle.

[0170] The network subsystem (811) of the first zone control unit (810) of FIG. 10a can transmit command data or operation result values ​​for driving to adjacent zone control units (see FIG. 1a), central control units (830), electronic control units (ECU) (850), and driving signal processing units (812) according to the location of the target device included in the received command signal. For example, when the central control unit (830) receives a command signal, the central control unit (830) can convert the command data into a packet or frame-type signal containing the command data according to the information of the target device to which the command signal is directed (e.g., identification ID of the vehicle control unit and actuator to which the target device is connected, protocol type, etc.) and transmit the command data to all zone control units or domain control units (not shown) using a TSN-based communication protocol. Likewise, all zone control units can convert command data into packet or frame form command data according to the information of the target device directed by the command signal and transmit it to the central control unit (830), adjacent zone control unit (840), and electronic control unit (ECU) (850) via Ethernet, CAN, or LIN communication protocols. In particular, if the target in-vehicle device included in the command signal is an actuator directly connected to itself, the network subsystem (811) can transmit command data or a driving operation result value in the form of serial communication to the driving signal processing unit (812). That is, the network subsystem (811) can set the driving signal processing unit (812) as the same node as the central control unit (830), adjacent zone control unit (840), and electronic control unit (ECU).

[0171] The vehicle control system (800) can be used in automotive applications for powertrain, chassis, and body control modules, and can be used for many other purposes, particularly in relation to applications for body control modules.

[0172] The driving signal processing unit (812) of the first zone control unit (810) of FIG. 10b can be programmed to control actuators for headlights, air conditioning controllers, side mirrors, seats, mood lamps, power windows, door locks, soft closing, trunk door locks, power trunks, taillights, wipers, rear curtains, washers, wireless charging, telescopic, sunroofs, steering, etc. Additionally, the driving signal processing unit (812) may include a PWM generation unit (815) that directly drives door locks and windows by connecting to an external H-Bridge (not shown). Additionally, the ADC (Analog to Digital Convert, 818) of the driving signal processing unit (812) can receive multiple sensor input signals through a multiplexer (not shown). Additionally, the input / output interface (820) of the driving signal processing unit (812) may include serial communication ports such as I2C (Inter-Integrated Circuit), UART (Universal asynchronous receiver / transmitter), and SPI (Serial Peripheral Interface) for communication with internal and external peripheral devices. Additionally, the driving signal processing unit (812) may include an arithmetic unit (816), and the arithmetic unit (816) may interpret command data and transmit control parameters (e.g., prescale value, counter value, comparison value related to timer setting, and clock distribution value, clock count, output pattern, etc. related to pulse signal setting) which are driving calculation result values ​​to the timer (813) and the PWM generation unit (815).

[0173] The network subsystem (811) and the driving signal processing unit (812) illustrated in FIGS. 10a and 10b are connected using one of the input / output interfaces (820) and can communicate using SPI, UART, and I2C protocols. On the other hand, command data or driving operation result values ​​transmitted between the network subsystem (811), the central control unit (830), the adjacent zone control unit (840), and the electronic control unit (ECU) (850) can be packetized or framed and transmitted using one of the communication protocols of Ethernet, CAN, and LIN. In this way, the network subsystem (811) performs the functions of communication interface, routing, switching, and protocol conversion, and the driving signal processing unit (812) generates a driving signal using the received command data or driving operation result values, and the vehicle control system and vehicle control device of the present invention may include various embodiments that ensure the transmission of command data to a target device with enhanced safety functions. That is, the network subsystem (811) can achieve time synchronization of the entire vehicle network, low latency, and seamless transmission of data between nodes through high-speed TSN-based Ethernet communication and compliance with the 802.1CB standard, and the driving signal processing unit (812) may include a driving signal control unit (not shown) that enables direct control of the driving signal generation module of the upper system. Accordingly, the vehicle control system of the present invention is able to perform the task of accurately and seamlessly controlling devices within the vehicle through various embodiments such as register mirroring and signal tunneling methods.

[0174] The network subsystem (811) includes a plurality of communication interfaces, wherein the first communication interface among the plurality of communication interfaces is connected to an electronic control unit (ECU) (850), and the second communication interface among the plurality of communication interfaces is connected to a first communication port of a driving signal processing unit (812), and the communication protocols output from the first communication interface and the second communication interface may be different.

[0175] The driving signal processing unit (812) includes a communication controller, and when a communication error occurs between the first communication interface of the network subsystem (811) and the electronic control unit (ECU) (850), the driving signal processing unit (812) can mirror the packet transmitted by the network subsystem (811) through the communication controller and transmit it to the electronic control unit (ECU) (850).

[0176] FIG. 11 is an internal configuration block diagram of a vehicle control system (9) that forms a vehicle network according to another embodiment of the present invention.

[0177] The central control unit (900) of the vehicle control system (9) illustrated in FIG. 11 can generate and control various driving signals in conjunction with values ​​stored in registers (901, 916, 926). Through this, the central control unit (900) can perform real-time and integrated control of the first zone control unit (910), the second zone control unit (920), and the vehicle's driving, steering, braking, and body devices.

[0178] The vehicle control system (9) illustrated in FIG. 11 may largely include a central control unit (900), at least two zone control units (910, 920), and a plurality of electronic control units (ECUs) (933, 940). The vehicle control system (9) may further include a plurality of actuators (930, 932, 941, 942) and a plurality of sensors (931, 943). Here, the central control unit (900) can communicate with the zone control units (910, 920), the Advanced Driver Assistance System (ADAS), the chassis, the powertrain, and the vehicle body, and control devices within the vehicle.

[0179] The master register (901) within the central control unit (900) can receive and store various sensor data of the vehicle (e.g., brake pedal position, speed, steering angle, etc.) from the sensor unit (961, 962) and command data from the electronic control unit (ECU) (951, 952), and the master register (901) can also store driving calculation result values ​​calculated by a calculation unit (not shown).

[0180] The master register (901) can mirror stored sensor data, command data, and operation result values ​​for driving to the slave registers (916, 926), and the slave registers (916, 926) can store the mirrored sensor data, command data, and operation result values ​​for driving.

[0181] The driving signal processing unit (914, 924) can generate a driving signal using at least one of the sensor data, command data, and driving operation result value stored in the slave register (916, 926).

[0182] At least one of the plurality of computational devices (not shown) of the central control unit (900) receives sensor data and command data (e.g., actuator command data, driving, steering, brake command data, etc.) and calculates a computational result value for driving (e.g., control parameter values ​​for timers and controllers including prescale values, counter values, comparison values, etc.) and stores it at a specific address of the master register (901) for a certain period of time. When an error occurs in the computational device (not shown) of the first driving signal processing unit (914) or the second driving signal processing unit (924), the central control unit (900) can mirror the latest computational result value for actuator driving stored in the master register (901) to the first slave register (916) or the second slave register (926) connected to the driving signal processing unit where the error is detected.

[0183] A computing device (not shown) within a central control unit (900), an MCU subsystem (912, 922), a network subsystem (913, 921), and a driving signal processing unit (914, 924) within first and second zone control units (910, 920) can refer to data stored in a master register (901) and a slave register (916, 926) in real time. In particular, the driving signal processing unit (914, 924) can generate and control a driving signal using at least one of sensor data, command data, and a driving operation result value stored in the master register (901) or the slave register (916, 926).

[0184] The driving signal processing unit (914, 924) receives the status of the in-vehicle device controlled by the actuator (930, 942), transmits it to the master register (901) for updating, and in subsequent control cycles, the MCU subsystem (912, 922), the network subsystem (913, 921), and the driving signal processing unit (914, 924) can process signals by referring to the data updated in the master register (901).

[0185] Additionally, the central control unit (900) or zone control unit (910, 920) includes a monitoring device (not shown) and a safety register (not shown). The monitoring device activates a safety control signal and transmits it to an arithmetic unit (not shown) within the central control unit (900) when a value written to a specific address of a master register (901) or slave register (916, 926) used to generate a driving signal exceeds a predetermined threshold value. The arithmetic unit deactivates the driving operation result value after the generation of the safety control signal and transmits the safety operation result value previously stored in the safety register to the slave register (916, 926) or the driving signal processing unit (914, 924).

[0186] That is, the master register (901) of the central control unit (900) stores sensor data and command data generated in the vehicle in real time, and when a specific event occurs, calculates a driving operation result value using the sensor data and command data stored in real time, and transmits the calculated driving operation result value to the slave register (916, 926) of the zone control unit (910, 920) so that the actuator (930, 942) in the vehicle can be directly controlled.

[0187] Additionally, if an error occurs in a calculation unit (not shown) inside an electronic control unit (ECU) (951, 952) directly connected to the central control unit (900) or in a calculation unit (not shown) inside an electronic control unit (ECU) (933, 940) connected to the zone control unit (910, 920), the central control unit (900) can transmit the driving calculation result value stored in the master register (901) to a slave register (not shown) inside the electronic control unit (ECU) (951, 952, 93, 940).

[0188] Each of the zone control units (910, 920) may include a memory subsystem (911, 923), an MCU subsystem (912, 922), a network subsystem (913, 921), a driving signal processing unit (914, 924), a slave register (916, 926), and a NoC bus system (915, 925). Each of the first and second network subsystems (913, 921) of the zone control units (910, 920) may be connected to the central control unit (900) via TSN-based high-speed Ethernet communication. The first network subsystem (913) and the second network subsystem (921) may be connected to each other via low-speed Ethernet communication. Additionally, the first and second network subsystems (913, 921) and a plurality of electronic control units (ECUs) (933, 940) can be connected to each other via low-speed Ethernet communication or CAN / LIN communication.

[0189] The first zone control unit (910) can be connected to a plurality of first actuators (930, 931), a first sensor unit (931), and a first electronic control unit (ECU) (933) placed in the first zone of the vehicle. The first zone control unit (910) identifies a signal transmitted from the central control unit (900) or the second zone control unit (920), and if the target device of the received signal is directly connected to the first zone control unit (910), it activates the first drive signal processing unit (914) (e.g., power and clock supply, etc.).

[0190] After that, the first network subsystem (913) transmits the received signal to the first slave register (916) or the first driving signal processing unit (914). The first driving signal processing unit (914) can generate a driving signal using the received command data or a value stored at a specific address in the slave register and transmit it to the actuator (930) connected to it.

[0191] The first network subsystem (913) can analyze the input signal and transmit the input signal to the first driving signal processing unit (914), the central control unit (900), the second network subsystem (921), or the electronic control unit (ECU) (933) located in the corresponding zone.

[0192] FIG. 12 is a block diagram showing a detailed internal configuration of a central control unit (10) according to one embodiment of the present invention.

[0193] As illustrated in FIG. 12, a central control unit (10) according to one embodiment of the present invention may largely include a CPU subsystem (1000), a memory subsystem (1010), an MCU subsystem (1020), a network subsystem (1030), an input / output subsystem (1040), and a main NoC bus system (1070).

[0194] The central control unit (10) is connected to at least two zone control units (1091, 1092, 1093, 1094) and a TSN-based backbone network, and can also be connected to a plurality of domain controllers (not shown) and auxiliary driving devices (not shown).

[0195] The CPU subsystem (10000) may include three physically isolated high-performance cores (100_1, 1001_2, 1001_3) (e.g., Arm’s Cortex-65AE) in a hypervisorless structure, and each of the three high-performance cores can independently manage the vehicle’s multi-domain (chassis, body, powertrain domain) and operate as an application processor. Additionally, it includes an interrupt controller and a clock generation and monitoring unit to manage interrupts from peripheral devices within the system, and can generate and monitor clocks required for the entire system module.

[0196] The MCU subsystem (1020) may include multiple cores (1021_1, 1021_2, 1021_3), and the master register (not shown) stores and manages various device control command data generated by the MCU subsystem (1020), controls specific functions through event-based register mirroring, and can handle interrupts by checking for system errors. Additionally, one of the multiple cores (1021_1, 1021_2, 1021_3) processes real-time data, while the other core is responsible for monitoring the system status or detecting errors, managing the overall control flow of the system, recording the error when an error occurs, and executing corresponding commands as needed.

[0197] The memory subsystem (1010) manages data transfer between the computing device and peripheral devices in conjunction with the main NoC bus system (1070) and can be responsible for memory access. Here, the memory (1013) may include external DDR (Double Data Rate) memory and external Serial-NOR flash memory.

[0198] The NoC bus system (1070) is a switched fabric in which any master device is connected to any slave device and multiple master devices can be simultaneously connected to multiple slave devices.

[0199] Additionally, the DMA controller (1011) supports efficient data transfer between the memory (1013) and peripheral devices, and the Deep Packet Inspection (DPI) engine (1012) can identify malicious attacks from the outside by deeply analyzing data packets transmitted through the vehicle network.

[0200] The security subsystem (1050) may include a security processor equipped with dedicated memory, encryption, a random number generator, and other peripherals. Once the secure boot is complete, devices outside the security subsystem (1050), including the security processor, cannot directly access or control most of the hardware blocks inside the security subsystem (1050). The security subsystem (1050) can communicate with other computing devices through a mailbox.

[0201] The network subsystem (1030) can receive a package containing data, convert it to a specific format, and perform the process of creating a new package configured by adding additional information or copying existing information.

[0202] The network subsystem (1030) may include a first accelerator (1031), a second accelerator (1035), a protocol converter (1033), and a NoC subbus system (1034).

[0203] The first accelerator (1031) can perform legacy communication conversion between electronic control units (ECUs) (1090) on a hardware basis, namely CAN-CAN conversion, CAN-LIN conversion and LIN-LIN conversion, and may have multiple CAN / CAN-FD / LIN controllers, an LPP engine (Legacy Packet Processing Engine), and a dedicated DMA controller.

[0204] The second accelerator (1035) can perform routing functions between Ethernet ports based on hardware and has a multi-gigabit Ethernet communication interface (e.g., USXGMII, SGMII, RGMII), a plurality of Gigabit Media Access Controllers (XGMAC, 1036_1 to 1036_4) and an EPP engine (Ethernet Packet Processing Engine), complies with the IEEE TSN / AVB standard and the IEEE 1599-time stamp standard, and can perform MAC security and IPsec security for incoming packets. The EPP engine acts as a multi-port IEEE 802.3 Gigabit Ethernet switch / router, controls data flow through hardware packet classification, scheduling, and shaping, and can perform the function of interpreting Ethernet packets received at the Ethernet port based on software or hardware and switching them to the Ethernet port where the target node is located.

[0205] The EPP engine performs internal packet scheduling when traffic congestion or scheduling is required within the central control unit (10), and can decide to drop the input packets when communication is difficult due to a lack of capacity in the internal buffer.

[0206] The EPP engine may include a hardware-based classifier, which, upon receiving an incoming packet, can rapidly deconstruct the packet's internal structure and compare it with predefined rules regarding the header and payload. Specifically, it can determine the type and destination of the input packet through specific conditions (e.g., if statements, gate operations, parallel operations). That is, it can use a lookup table to identify items matching the packet's attributes and rapidly determine a forwarding or drop action.

[0207] The EPP engine can use a MAC HASH table as a lookup table for L2 switching and can determine the port forwarding of packets using a MAC address (corresponding to a device in the vehicle) and a VLAN ID (an ID that groups MAC addresses).

[0208] A MAC hash table is divided into a general area and a collision area, and the collision area can serve as a space to handle overflows in the general area. For example, a collision may occur when addresses A and B are entered, and a collision space can be used to prevent such collisions. In other words, if address A matches packet 1, the structure can have a pointer written in packet 1 stating, "If it does not match, refer to the collision space."

[0209] However, using a hash algorithm, it can be difficult to find out which entry in the table contains the MAC address and what contents it has when a MAC address is received. Therefore, a hash value is generated using a specific algorithm with the MAC address and VALAN ID, and the hash value is used as an address to find the entry based on the address.

[0210] The contents to be looked up are stored in 188-bit memory, and the 188-bit memory contents may include table resizing, access information, and action entries.

[0211] The contents of the action entry field may include actions such as discarding the input packet, forwarding it to a specific Ethernet port, placing the traffic into a specific scheduler, passing the traffic to a control center, PUNTing it to the CPU if it is a new packet, and searching multiple tables to override the packet for packets that need to be processed in a nested manner.

[0212] There may be multiple lookup tables including MAC tables, routing tables, and ACL tables, and among the multiple tables, an action match is determined by priority, and forwarding or routing can be determined.

[0213] The first priority is the Access Control List (ACL) table; if an input packet matches the contents stored in the ACL, the determined action in the ACL table can be executed. The second priority determines whether the input packet is IPsec processed, and if so, a decryption action can be performed. The third priority can process data delivered by the host CPU. Subsequently, processing can be performed to block streams and DDoS attacks, or to PUNT packets to the host CPU when invalid or unknown packets arrive.

[0214] Ultimately, through the MAC hash table, matches can be found based on hardware-configured rules, and forwarding actions can be determined.

[0215] In addition, it may include a field that determines whether a specific MAC address will be operated statically or dynamically.

[0216] The protocol converter (1033) can be responsible for conversion and forwarding between heterogeneous packet formats and can be implemented and executed as a software-based processor. That is, it can perform at least one of protocol conversion between Ethernet and CAN and protocol conversion between Ethernet and LIN.

[0217] A CAN message converted into an Ethernet packet through a protocol converter (1033) can be transmitted through an EPP engine to an Ethernet port containing the destination node of the CAN message. Additionally, an Ethernet packet transmitted through the EPP engine can be converted into a CAN message through a protocol converter (1033) and transmitted by an LPP engine to a CAN port containing a target node.

[0218] The network subsystem (1030) can automatically route specific types of frames (see FIG. 41a and FIG. 41b).

[0219] The network subsystem (1030) further includes a parsing unit (not shown), and the parsing unit can extract data in a specific field from a specific type of frame (see FIG. 41a and FIG. 41b).

[0220] Packages contain protocol-dependent addresses and payloads, and the format and usage of addresses vary depending on the communication protocol. For example, Ethernet uses a 48-bit Media Access Control (MAC) address to identify the destination node used for unicast or multicast packets, while CAN uses an 11-bit or 29-bit message identifier to identify the message content used for multicast. FlexRay uses temporal relationships to identify the message content used to multicast messages.

[0221] The input / output subsystem (1040) includes an external device controller and can provide a connection between the network subsystem (1030) and the external device. Here, the external device controller may include an eMMC, a USB 2.0 device, an Ethernet MAC, etc. The input / output subsystem (1040) may include a Serial Peripheral Interface (SPI), I2C, Pulse Density Modulation (PDM), UART, a CAN communication controller, and an ADC.

[0222] In FIG. 12, the central control unit (10) may include a port capable of receiving an actuator driving signal transmitted from a zone control unit (1091, 1092, 1093, 1092) or an electronic control unit (ECU) (1090), and if the actuator driving signal received by the port includes a predetermined signal pattern corresponding to an actuator connected to itself, the central control unit may have a path to bypass the actuator driving signal and transmit it to the actuator connected to itself.

[0223] FIG. 13 is a block diagram showing a detailed internal configuration of a central control unit (11) according to another embodiment of the present invention.

[0224] FIG. 13 further includes a drive control unit (1180) in addition to the central control unit (10) shown in FIG. 12, so that a plurality of actuators (1196, 1197) (e.g., actuator for windows, actuator for mirrors, etc.) can be directly driven.

[0225] The drive control unit (1180) is composed of islanded blocks with a chip-in-chip concept and can be connected to other components via SPI (Serial Peripheral Interface).

[0226] The drive control unit (1180) can process actuator command data received through at least one communication controller of the input / output subsystem (1140), generate an actuator driving signal corresponding to the command data, and transmit it to the actuator (1196, 1197). Here, the actuator command data may include a target device, a target operation, and a target state, and an example of a driving signal may include a PWM signal. Here, at least one communication controller may include one of SPI, I2C, or UART communication. The drive control unit (1180) can interpret and calculate the received actuator command data to generate a PWM signal corresponding to the target output and transmit it to the corresponding actuator.

[0227] The network subsystem (1130) can identify a message identifier or address within a packet for a communication packet received through an electronic control unit (ECU) (1190, 1195) and a first to fourth zone control unit (1191 to 1194), and if the target device of the packet is a first actuator (1196) or a second actuator (1197) connected to a drive control unit (1180), it can extract data (e.g., actuator command data) in the payload of the packet and transmit it to an input / output subsystem (1140), and the communication controller inside the input / output subsystem (1140) can convert the data into a serial communication protocol and transmit it to the drive control unit (1180).

[0228] The drive control unit (1180) can identify the target actuator to be controlled from the actuator command data transmitted from the communication controller of the input / output subsystem (1140), generate a PWM signal corresponding to the target output for the target state, and transmit it to the target actuator. Here, the communication packet has a device ID data field, and the first accelerator (1131) and the second accelerator (1135) extract the device ID and data and transmit them to the main NoC bus system (1170), and the main NoC bus system (1170) (or MUC subsystem (1120)) can transmit the command data to the input / output subsystem (1140) when the device ID is identified as an actuator directly connected to itself. For example, when a signal to lower the passenger window is input through a switch connected to a CAN electronic control unit (ECU) (1190), the CAN electronic control unit (ECU) (1190) can generate a packet containing its CAN ID (i.e., target device ID) and a lower command signal and transmit it to a central control unit (11).

[0229] The first accelerator (1131) of the central control unit (11) can identify a device ID by interpreting the received packet and identify a target actuator by searching a table in which device ID-actuator connection information is stored in advance.

[0230] The first accelerator (1131) identifies that the target actuator is an actuator connected to it, parses command data from a packet, and transmits it to the main NoC bus system (1170), and the main NoC bus system (1170) can transmit the command data to the input / output subsystem (1140). The input / output subsystem (1140) can select at least one of at least one communication controller to convert the command data into a serial communication protocol and transmit it to the drive control unit (1180).

[0231] When a CAN electronic control unit (ECU) (1198) that receives command data for a safety actuator (1196) important for passenger safety is directly connected to a drive control unit (1180) in the central control unit (11) of FIG. 13, the drive control unit (1180) receives command data for the safety actuator transmitted by the CAN electronic control unit (ECU) (1198) through a CAN controller (not shown) within the drive control unit (1180), and a computing device (not shown) and a drive signal generator (not shown) within the drive control unit (1180) can generate a signal for driving the safety actuator. Through such a flexible internal configuration, for signals related to actuators requiring urgent command transmission, the drive control unit (1180) can interpret the command itself and control the actuator without using the internal resources of the central control unit (11), namely the MCU subsystem (1120) and the network subsystem (1130), so that when multiple messages are input to the central control unit (11) simultaneously, the processing delay of the urgent message can be reduced.

[0232] FIG. 14 is a block diagram showing a detailed internal configuration of a first zone control unit (12) according to another embodiment of the present invention.

[0233] As illustrated in FIG. 14, the first zone control unit (12) may largely include a memory subsystem (1210), an MCU subsystem (1220), a network subsystem (1230), an input / output subsystem (1240), a drive control unit (1280), and a main NoC bus system (1270). The first zone control unit (12) may be connected to a plurality of electronic control units (ECUs) (1290, 1291, 1295, 1298) assigned to the first zone, a plurality of actuators (1296, 1297), second and third zone control units (1292, 1294) and a central control unit (1293) (CCU) placed in adjacent zones.

[0234] The MCU subsystem (1220) may include three core wrappers of dual-core lockstep and may control specific functions through event-based register mirroring.

[0235] The memory subsystem (1210) works in conjunction with the main NoC bus system (1270) to manage data transfer between the computing device and peripheral devices and can handle memory access. Here, the memory (1213) may include external DDR (Double Data Rate) memory and / or external Serial-NOR flash memory. Additionally, the DMA controller (1211) supports efficient data transfer between the memory (1213) and peripheral devices, and the Deep Packet Inspection (DPI) engine (1212) can identify malicious attacks from the outside by deeply analyzing data packets transmitted through the network.

[0236] The security subsystem (1250) may include a security processor equipped with dedicated memory, encryption, a random number generator, and other peripherals. Once the secure boot is complete, devices outside the security subsystem, including the security processor, cannot directly access or control most of the hardware blocks inside the security subsystem. The security subsystem (1250) can communicate with other processors through a mailbox.

[0237] The network subsystem (1230) may include a first accelerator (1231), a second accelerator (1235), and a protocol converter (1233).

[0238] The first accelerator (1231) performs legacy communication conversion between CAN or LIN-based electronic control units (1290, 1291) on a hardware basis, namely CAN-CAN conversion and CAN-LIN conversion, and may include a plurality of CAN / CAN-FD / LIN controllers, an LPP engine (Legacy Packet Processing Engine), and a dedicated DMA controller.

[0239] The second accelerator (1235) performs routing functions between Ethernet ports based on hardware and may include a multi-gigabit Ethernet communication interface (e.g., USXGMII, SGMII, RGMII), a plurality of Gigabit Media Access Controllers (1236_1, 1236_2) and an EPP engine (Ethernet Packet Processing Engine), complies with the IEEE TSN / AVB standard and the IEEE 1599-time stamp standard, and can perform MAC security and IPsec security for incoming packets. The EPP engine performs the role of a multi-port IEEE 802.3 Gigabit Ethernet switch / router, controls data flow through hardware packet classification, scheduling, and shaping, and can perform the function of interpreting Ethernet packets received at the Ethernet port based on hardware and switching them to the Ethernet port where the target node is located.

[0240] The EPP engine performs internal packet scheduling when traffic congestion or scheduling is required within the central control unit (10), and can decide to drop the input packets when communication is difficult due to a lack of capacity in the internal buffer.

[0241] The EPP engine may include a hardware-based classifier, which, upon receiving an incoming packet, can rapidly deconstruct the packet's internal structure and compare it with predefined rules regarding the header and payload. Specifically, it can determine the type and destination of the input packet through specific conditions (e.g., if statements, gate operations, parallel operations). That is, it can use a lookup table to identify items matching the packet's attributes and rapidly determine a forwarding or drop action.

[0242] The EPP engine can use a MAC HASH table as a lookup table for L2 switching and can determine the port forwarding of packets using a MAC address (corresponding to a device in the vehicle) and a VLAN ID (an ID that groups MAC addresses).

[0243] A MAC hash table is divided into a general area and a collision area, and the collision area can serve as a space to handle overflows in the general area. For example, a collision may occur when addresses A and B are entered, and a collision space can be used to prevent such collisions. In other words, if address A matches packet 1, the structure can have a pointer written in packet 1 stating, "If it does not match, refer to the collision space."

[0244] However, using a hash algorithm, it can be difficult to individually locate the corresponding entry in the table and determine its contents when a MAC address is input. Therefore, a hash value is generated using a specific algorithm with the MAC address and VLAN ID, and this hash value is used as an address, allowing the entry to be found based on the address.

[0245] The contents to be looked up are stored in 188-bit memory, and the 188-bit memory contents may include table resizing, access information, and action entries.

[0246] The contents of the action entry field may include actions such as discarding the input packet, forwarding it to a specific Ethernet port, placing the traffic into a specific scheduler, passing the traffic to a control center, PUNTing it to the CPU if it is a new packet, and searching multiple tables to override the packet for packets that need to be processed in a nested manner.

[0247] There may be multiple lookup tables including MAC tables, routing tables, and ACL tables, and among the multiple tables, an action match is determined by priority, and forwarding or routing can be determined.

[0248] The first priority is the Access Control List (ACL) table; if an input packet matches the contents stored in the ACL, the determined action in the ACL table can be executed. The second priority determines whether the input packet is IPsec processed, and if so, a decryption action can be performed. The third priority can process data delivered by the host CPU. Subsequently, processing can be performed to block streams and DDoS attacks, or to PUNT packets to the host CPU when invalid or unknown packets arrive.

[0249] Ultimately, through the MAC hash table, matches can be found based on hardware-configured rules, and forwarding actions can be determined.

[0250] In addition, it may include a field that determines whether a specific MAC address will be operated statically or dynamically.

[0251] The protocol converter (1233) may include a computing device (not shown) and is responsible for conversion and forwarding between heterogeneous packet formats. For example, it can perform protocol conversion between Ethernet-CAN and Ethernet-LIN. A CAN message converted into an Ethernet packet through the protocol converter (1233) can be transmitted to an Ethernet port containing the target node of the CAN message through the EPP engine. Additionally, an Ethernet packet transmitted through the EPP engine can be converted into a CAN message through the protocol converter (1233) and transmitted to a CAN port containing the target node by the LPP engine.

[0252] The input / output subsystem (1240) includes an external device controller and can provide a connection between the main NoC bus system (1270) and an external device. Here, the external device controller may include an eMMC, a USB 2.0 device, an Ethernet MAC, etc. The input / output subsystem (1240) may further include an SPI, I2C, PDM, UART, CAN communication controller, and an ADC.

[0253] A plurality of actuators (1296, 1297) (e.g., actuator for a window, actuator for a mirror, etc.) can be directly connected to the first zone control unit (12).

[0254] The drive control unit (1280) can process actuator command data received through at least one of the at least one communication controllers of the input / output subsystem (1240), generate an actuator driving signal corresponding to the command data, and transmit it to the target actuator. Here, the actuator command data may include a target device, a target operation, and a target state, and an example of the driving signal may include a PWM signal. Here, at least one communication controller may include one of SPI, I2C, or UART communication. The drive control unit (1280) can interpret and calculate the received actuator command data to generate a PWM signal corresponding to the target output and transmit it to the corresponding actuator.

[0255] In FIG. 13, the first zone control unit (12) may include a port capable of receiving an actuator driving signal transmitted from a zone control unit (1292, 1294), a central control unit (1293), or an electronic control unit (ECU) (1290, 1291), and if the actuator driving signal received by the port includes a predetermined signal pattern corresponding to an actuator connected to itself, the actuator driving signal may be bypassed and transmitted to an actuator (1296, 1297) connected to itself.

[0256] The network subsystem (1230) of FIG. 14 identifies a message identifier or address for a packet or frame received through a CAN electronic control unit (ECU) (1290), a LIN electronic control unit (ECU) (1291), a second zone control unit (1292), a third zone control unit (1294), and a central control unit (1293). If the target device of the packet is a first actuator (1296) or a second actuator (1298) connected to a drive control unit (1280), the network subsystem extracts data (e.g., actuator command data) in the payload of the packet and transmits it to an input / output subsystem (1240). A communication controller inside the input / output subsystem (1240) can convert the command data into a serial communication protocol and transmit it to the drive control unit (1280).

[0257] The drive control unit (1280) can identify the target actuator to be controlled from the actuator command data transmitted from the communication controller of the input / output subsystem (1240), generate a PWM signal corresponding to the target output for the target state, and transmit it to the target actuator. Here, the communication packet contains a device ID and a data field, and the first accelerator (1231) and the second accelerator (1235) extract the device ID and data and transmit them to the main NoC bus system, and the main NoC bus system (1270) (or MUC subsystem (1220)) can transmit the command data to the input / output subsystem (1240) when the device ID is identified as an actuator directly connected to it. For example, when the first zone control unit (12) is located in the passenger seat and a signal to lower the passenger seat window is input through a switch connected to the CAN electronic control unit (ECU) (1290), the CAN electronic control unit (ECU) (1290) can generate a packet containing its CAN ID (i.e., target device ID) and a lower command signal and transmit it to the first zone control unit (2). The first accelerator (1231) of the first zone control unit (12) can interpret the received packet to identify the CAN ID and identify the target actuator by searching a table in which CAN ID actuator connection information is stored in advance.

[0258] The first accelerator (1231) identifies that the target actuator is an actuator connected to it, parses command data from a packet, and transmits it to the main NoC bus system (1270), and the main NoC bus system (1270) can transmit the command data to the input / output subsystem (1240). The input / output subsystem (1240) can convert the command data into a serial communication protocol through at least one communication controller and transmit it to the drive control unit (1280).

[0259] In another embodiment, if it is determined that a command signal for controlling an actuator (1296) in the first zone is received only through a CAN ECU (1295) in the first zone, the CAN ECU (1295) can be directly connected to an input / output subsystem (1240), and a CAN controller (not shown) in the input / output subsystem (1240) can extract command data from the received packet and transmit it to a drive control unit (1280).

[0260] Meanwhile, if a CAN electronic control unit (ECU) (1298) that receives a command signal for a safety actuator (1297) important for passenger safety is directly connected to a drive control unit (1280), a CAN controller (not shown) within the drive control unit (1280) can extract command data for the safety actuator from the received packet, and a computing device (not shown) and a drive signal generator (not shown) within the drive control unit (1280) can generate a signal for driving the safety actuator using the extracted command data. Through such a flexible internal configuration, for signals related to actuators requiring urgent command transmission, the drive control unit (1280) can interpret the command itself and control the actuator without using the internal resources of the first zone control unit (12), namely the MCU subsystem (1220) and the network subsystem (1230), so that when multiple messages are simultaneously input to the first zone control unit (12), the processing delay of the urgent message can be reduced.

[0261] FIG. 15 is a drawing for explaining a method of directly controlling an actuator of a first zone control unit (13) according to another embodiment of the present invention.

[0262] As illustrated in FIG. 15, the MCU subsystem (1320), network subsystem (1330), and drive control unit (1380) within the first zone control unit (13) of the present invention are supplied with independent power and clocks, thereby minimizing the interruption of control of the actuator due to a single point of error.

[0263] The drive control unit (1380) may include an arithmetic unit (not shown), a configuration register (1381), and a drive signal generator (not shown). The arithmetic unit of the drive control unit (1380) interprets received actuator command data to calculate control parameter values ​​required to generate a PWM signal, and records the calculated control parameter values ​​in the configuration register (1381). The drive signal generator of the drive control unit (1380) can generate an actuator driving signal (e.g., a PWM signal) using the values ​​of the configuration register (1381).

[0264] If an error occurs in the arithmetic unit of the drive control unit (1380), the system manager subsystem (1360) can detect the error and transmit an error signal to the MCU subsystem (1320). At least one arithmetic unit of the MCU subsystem (1320) can fetch actuator command data transmitted to the drive control unit (1380) via the main NoC bus system (1370), execute the same program used by the arithmetic unit of the drive control unit (1380) to calculate an operation result value for driving the actuator (e.g., control parameter value for timer and controller, prescale value, counter value, comparison value, clock distribution value, output pattern value, etc.), and write the calculated operation result value for driving the actuator to the configuration register (1381) via the register interface (see FIG. 37) of the drive control unit (1380) through the main NoC bus system and the input / output subsystem.

[0265] The first zone control unit (13) may include a signal tunneling module that enables the consistent and uninterrupted transmission of data frames in different network environments while securely protecting packets containing specific types of data frames. That is, it may include a signal tunneling module that transmits the result of an operation for driving an actuator, which is input from the outside or generated internally, to the register of the driving signal generator within the driving control unit (1380). The signal tunneling module may include the first accelerator (1331), the second accelerator (1335), the protocol converter (1333), the main NoC bus system (1370), the input / output subsystem (1340), and the register interface of the driving signal generator of the network subsystem (1330). Through this, the first zone control unit (13) is able to continuously control the actuator connected to it without interruption, even if an error occurs in the operation device of the driving control unit (1380).

[0266] The signal tunneling module taught in this specification performs the function of encapsulating data into a payload of an Ethernet or CAN frame, converting it into a serial-parallel communication protocol, and transmitting it to a remote register, and may include software and hardware devices involved in transmitting register values ​​to a remote register or a driving signal generator located in a system that is physically or electrically separated from a specific computing device.

[0267] The network subsystem (1330) may further include a 10BASE-T1S communication controller (1390), and the first zone control unit (13) can communicate with each electronic control unit (ECU) even when at least one Ethernet electronic control unit (ECU) (1399) is connected to a single bus. This allows the number of harnesses in the vehicle to be significantly reduced.

[0268] FIG. 16 is a diagram showing a signal path within a zone control unit (1400) in a vehicle control system (14) for a zone architecture according to another embodiment of the present invention.

[0269] As illustrated in FIG. 16, a zone control unit (1300) constituting a vehicle control system (14) for a zone architecture may include a protocol converter (1410) and a driving signal processing unit (1420).

[0270] A time-critical first actuator (1450) located close to the zone control unit (1400) of FIG. 16 or requiring a short delay time can be directly connected to the zone control unit (1400). On the other hand, second and third actuators (1460, 1470) located far from the zone control unit (1400) or having lower priority can be controlled via a CAN / LIN / Ethernet electronic control unit (ECU) (1430, 1440). This allows for a reduction in the number of electronic control units (ECUs) and wiring harnesses.

[0271] As illustrated in FIG. 16, actuator command data in a packet or frame signal (S) input to a zone control unit (1400) can control actuators (1450, 1460, 1470) through a first path (A) or a second path (B).

[0272] FIGS. 17a to 17d are drawings showing some operation of the network subsystems (1230, 1330) of FIGS. 14 and FIG. 15 corresponding to the first path (A) shown in FIG. 16.

[0273] The first accelerator (1520) of the network subsystem (15) illustrated in FIG. 17a, FIG. 17c and FIG. 17d can perform protocol conversion and translation between CAN-CAN, CAN-LIN, and LIN-LIN. That is, a CAN / LIN frame (S1) received by a CAN / LIN port (not shown) of the network subsystem (15) can be analyzed by the first accelerator (1520) and transmitted to a CAN port, a LIN port, or a first protocol converter (1510) of the network subsystem (15) according to the information within the frame and a routing table stored in memory (not shown).

[0274] The second accelerator (1530) illustrated in FIGS. 17a, 17b, and 17d is a hardware engine for switching between Ethernet ports of various speeds and may include MACsec, IPsec, traffic shaper, packet classifier, scheduler, time synchronization, frame redundancy transmission, and deletion functions for an input Ethernet packet (S2). Specifically, the second accelerator (1530) may parse the L2 or L3 layer for an input Ethernet packet (S2), extract fields necessary for packet processing, and perform an L2 or L3 routing table lookup. It may process packets and make packet forwarding decisions based on priority, the routing table lookup results, and the parsed data (Ethernet type). The switching decision of the second accelerator (1530) may be made based on two criteria: the input port information of the packet and the destination information of the packet.

[0275] The first protocol converter (1510) illustrated in FIGS. 17a and 17d executes software that performs conversion between Ethernet and legacy protocols (e.g., CAN / LIN). That is, it shows that the first accelerator (1520), the first protocol converter (1510), and the second accelerator (1530) operate in conjunction when an input Ethernet packet (S2) needs to be converted into a CAN / LIN frame (S1) or when a CAN / LIN frame (S1) needs to be converted into an Ethernet packet (S2).

[0276] A network device (16) according to one embodiment of the present invention illustrated in FIG. 18 may include a network subsystem (1600) and a drive control unit (1660). The drive control unit (1660) may directly transmit a driving signal to an actuator (1670).

[0277] A network subsystem (1600) can determine an internal system path that an input packet (or frame) must traverse based on an identifier of an input device and a location of a target device included in a specific field within the input packet (or frame). The network subsystem (1600) can perform protocol conversion or data parsing on the packet (or frame) flowing through the determined path and transmit it to at least one of an Ethernet communication interface, a CAN communication interface, a LIN communication interface, and a drive control unit (1660) connected to the target device. Here, the location of the target device can be classified into adjacent nodes and self nodes (see AN and SN in FIGS. 26 to 28). The adjacent node (AN) may include a central control unit and a zone control unit. The self node (SN) may include an actuator and an electronic control unit (ECU) directly connected to the zone control unit.

[0278] The network subsystem (1600) may include a first accelerator (1620) that processes a CAN / LIN frame (S1) input to at least one of a plurality of CAN / LIN communication interfaces (not shown) and outputs it to at least one of a plurality of CAN / LIN communication interfaces (not shown).

[0279] The network subsystem (1600) may include a second accelerator (1630) that processes an Ethernet packet (S2) input to at least one of a plurality of Ethernet communication interfaces (not shown) and outputs it to at least one of a plurality of Ethernet communication interfaces (not shown).

[0280] The network subsystem (1600) may include a first protocol converter (1610) that performs protocol conversion between an Ethernet packet (S2) and a CAN / LIN frame (S1).

[0281] The network subsystem (1600) may further include a second protocol converter (1640) that converts an Ethernet packet (S2) and a CAN / LIN frame (S1) into at least one serial communication protocol, or converts specific data within the Ethernet packet (S2) and the CAN / LIN frame (S1) into at least one serial communication protocol and transmits it to a drive control unit (1660).

[0282] The first accelerator (1620) can operate by determining a routing path based on hardware or software as a CAN and LIN communication message transmission and reception block.

[0283] The first accelerator (1620) can transmit an input CAN / LIN frame (S1) to a CAN / LIN communication interface, a first protocol converter, a second protocol converter (1640), or a drive control unit (1660) connected to the first accelerator (1620) according to an action list stored in the first table (1601). Here, the action list may include a predetermined transmission path according to the packet type.

[0284] When a CAN / LIN frame (S1) is received, the first accelerator (1620) may attach reception time information to the packet in the form of a timestamp and transmit it to the first protocol converter (1630), and store the timestamp in the first memory (1603). The packets attached with the reception timestamp and the transmission timestamp may each include a serial number and a source communication interface. By using the reception timestamp and the transmission timestamp, a connection can be established between a specific packet transmitted from the output communication interface and the timestamp stored in the first memory (1603). Here, the serial number may be generated and incremented whenever each CAN and LIN communication interface receives a new packet. The serial number is a counter that increases by 1 for each next packet, and the source communication interface may be used to distinguish the serial numbers generated from each CAN and LIN communication interface. Through this, packets transmitted from multiple output communication interfaces can be clearly distinguished and managed.

[0285] The second accelerator (1630) can operate by determining a routing path based on hardware or software as an Ethernet communication packet transmission and reception block.

[0286] The second accelerator (1630) can transmit the input Ethernet packet (S2) to an Ethernet communication interface connected to the second accelerator (1620), a first protocol converter, a second protocol converter (1640), or a drive control unit (1660) according to an action list stored in the second table (1602).

[0287] The network subsystem (1600) may include two channels of DMA controllers (not shown). Each of the two channels of DMA controllers can directly transfer data between the first memory (1603) and the first accelerator (1620) and between the second memory (1604) and the second accelerator (1630). The DMA controller designated as channel "0" has a higher priority than the DMA controller designated as channel "1", and the DMA controller of channel "0" can operate first upon receiving the same data transfer request.

[0288] The first protocol converter (1610) is a communication protocol converter that converts CAN, CAN-FD, and LIN protocols into Ethernet protocols, or converts Ethernet protocols into CAN, CAN-FD, and LIN protocols.

[0289] The second protocol converter (1640) may include a parsing unit that extracts command data (CMD) or driving operation result values ​​(DPV) in a predetermined field within an Ethernet packet (S2) and a plurality of serial communication controllers. The parsing unit may convert the extracted command data (CMD) or driving operation result values ​​(DPV) into a serial communication method (e.g., SPI, I2C, UART) or GPIO signal and transmit it to the driving control unit (1660). Each of the plurality of serial communication controllers may change to a different communication medium according to a configuration value transmitted from the upper unit. At least some of the plurality of serial communication controllers may receive and transmit the extracted data in the same way. Depending on a selection signal transmitted from the upper unit, at least some of the plurality of serial communication controllers may be connected to or disconnected from the driving control unit (1660). Each of the plurality of serial communication controllers may transmit data based on at least one of serial communication protocols such as SPI / I2C / UART.

[0290] The second protocol converter (1640) may further include the protocol conversion component of the first protocol converter (1610) to perform the function of converting protocols between Ethernet and CAN / LIN. That is, in the event of a functional failure of the first protocol converter (1610), the second protocol converter (1640) may receive a CAN / LIN frame (S1) input to the first accelerator (1620), convert it into an Ethernet communication protocol, and transmit it to the second accelerator (1630), or the second protocol converter (1640) may receive an Ethernet packet (S2) input to the second accelerator (1630), convert it into a CAN / LIN communication protocol, and transmit it to the first accelerator (1620).

[0291] The first and second accelerators (1620, 1630) can parse and extract command data (CMD) or driving operation result values ​​(DPV) from Ethernet packets (S2) and CAN / LIN frames (S1). That is, in the event of a functional failure of the second communication protocol converter (1640) and the operation device (not shown) within the driving control unit (1660), the first and second accelerators (1620, 1630) can extract command data (CMD) or driving operation result values ​​(DPV) from the input packet (or frame) and transmit them directly to the driving control unit (1660). The driving control unit (1660) can generate a signal for driving the actuator using the command data (CMD) or driving operation result values ​​(DPV).

[0292] The first table (1601) is a CAN, CAN-FD, LIN communication routing table, and the second table (1602) may be an Ethernet communication routing table. Here, the routing table may be a table containing a destination node according to the header information of an input packet (or frame).

[0293] The third table (1605) may be a protocol conversion routing table used when converting CAN, CAN-FD, LIN communication to Ethernet communication, or converting Ethernet communication to CAN, CAN-FD, LIN communication. Here, the protocol conversion routing table may be a table containing protocol conversion methods based on the source node and destination node of the input packet. The first protocol converter (1610) may perform conversion between heterogeneous protocols based on the third table (1605).

[0294] The second memory (1604) is a local memory connected to the second accelerator (1630) and can store the original and copy of an Ethernet packet (S2) and an Ethernet packet transmitted from the first protocol converter (1610) (wherein the Ethernet packet is a packet in which a CAN / LIN frame has been converted into an Ethernet structure). If the destination node of a packet input to the second accelerator (1630) is the second accelerator (1630), the second accelerator (1630) retrieves the original and copy stored in the second memory (1604). The second accelerator (1630) can transmit each of the retrieved original and copy to an Ethernet communication interface other than the Ethernet communication interface where the first packet was input. Additionally, the Ethernet communication interface transmitting the original and the Ethernet communication interface transmitting the copy may be different.

[0295] The drive control unit (1660) can receive command data (CMD) or a driving operation result value (DPV) transmitted from the network subsystem (1600), generate an actuator driving signal (DS) through self-processing, and transmit it to the actuator (1670).

[0296] The drive control unit (1660) may include Ethernet and CAN / CAN-FD / LIN communication interfaces. If a failure occurs in the second protocol converter (1640), the drive control unit (1660) can directly receive the Ethernet packet (S2) and CAN / CAN-FD / LIN packet (S1) transmitted by the first accelerator (1620) or the second accelerator (1630) and drive the actuator (1670).

[0297] The network subsystem (1600) may further include a path controller (1650). The path controller (1650) may be connected to the first accelerator (1620), the second accelerator (1630), the first protocol converter (1610), and the second protocol converter (1640), respectively.

[0298] The path controller (1650) can detect functional failures of the first accelerator (1620), the second accelerator (1630), the first protocol converter (1610), and the second protocol converter (1540) itself. Additionally, the path controller (1650) can detect connection failures on a path including the first accelerator (1620) - first protocol converter (1610) path, the first accelerator (1620) - second protocol converter (1640) path, the first accelerator (1620) - drive control unit (1660) path, the second accelerator (1630) - first protocol converter (1610) path, the second accelerator (1630) - second protocol converter (1640) path, the second accelerator (1630) - drive control unit (1660) path, and the second protocol converter (1640) - drive control unit (1640) path.

[0299] The path controller (1650) can transmit a CAN / LIN frame (S1) input to the first accelerator (1620) through one of the paths: the first accelerator (1620) - the first protocol converter (1610) - the second accelerator (1630), the first accelerator (1620) - the second protocol converter (1640) - the second accelerator (1630), the first accelerator (1620) - the second protocol converter (1640) - the drive control unit (1660), or the first accelerator (1620) - the drive control unit (1660).

[0300] The path controller (1650) can transmit an Ethernet packet (S2) input to the second accelerator (1630) through one of the following paths: the second accelerator (1620) - the first protocol converter (1610) - the first accelerator (1620), the second accelerator (1630) - the second protocol converter (1640) - the first accelerator (1620), the second accelerator (1630) - the second protocol converter (1640) - the drive control unit (1660), or the second accelerator (1630) - the drive control unit (1660).

[0301] The path controller (1650) is connected to the first accelerator (1620) and the second accelerator (1630) and can share information about the input packet. If the device to which the input packet is directed is an actuator connected to the drive control unit (1660), the path controller (1650) can control the first accelerator (1620) or the second accelerator (1630) to transmit the input Ethernet packet (S2) or CAN / LIN frame (S1) directly to the second protocol converter (1640) or the drive control unit (1660).

[0302] If a functional failure occurs in the first protocol converter (1610), the path controller (1650) can transmit a CAN / LIN frame (S1) input to the first accelerator (1620) through the first accelerator (1620) - second protocol converter (1640) - second accelerator (1630) path, the first accelerator (1620) - second protocol converter (1640) - drive control unit (1660) path, or the first accelerator (1620) - drive control unit (1660) path.

[0303] If a functional failure occurs in the first protocol converter (1610), the path controller (1650) can transmit the Ethernet packet (S2) input to the second accelerator (1630) through the second accelerator (1630) - second protocol converter (1640) - first accelerator (1620) path, the second accelerator (1630) - second protocol converter (1640) - drive control unit (1660) path, or the second accelerator (1630) - drive control unit (1660).

[0304] If a functional failure occurs in the second protocol converter (1640), the path controller (1650) can transmit a CAN / LIN frame (S1) input to the first accelerator (1620) through one of the paths: the first accelerator (1620) - the first protocol converter (1610) - the second accelerator (1630), the first accelerator (1620) - the first protocol converter (1610) - the second accelerator (1630) - the drive control unit (1660), or the first accelerator (1620) - the drive control unit (1660).

[0305] If a functional failure occurs in the second protocol converter (1620), the path controller (1650) can transmit the Ethernet packet (S2) input to the second accelerator (1630) through one of the paths: second accelerator (1630) - first protocol converter (1610) - first accelerator (1620), second accelerator (1630) - first protocol converter (1610) - first accelerator (1620) - drive control unit (1660), or second accelerator (1630) - drive control unit (1660).

[0306] If a fault occurs in the path between the first accelerator (1620) and the first protocol converter (1610), the path controller (1650) can transmit the CAN / LIN frame (S1) input to the first accelerator (1620) through the first accelerator (1620) - second protocol converter (1640) - second accelerator (1630) path, the first accelerator (1620) - second protocol converter (1640) - drive control unit (1660) path, or the first accelerator (1620) - drive control unit (1660) path.

[0307] In this way, the path controller (1650) can transmit packets input to the path excluding the fault path to the target node without interruption in response to the type of fault on the path. Here, the target node may include a plurality of Ethernet communication interfaces connected to an Ethernet electronic control unit (ECU), a central control unit and a zone control unit, a plurality of CAN / LIN communication interfaces connected to a CAN / LIN electronic control unit (ECU), and a drive control unit (1660) connected to an actuator.

[0308] When the fault signal is received, the path controller (1650) can determine the path of the packet with priority over the routing operation of the first accelerator (1620) and the second accelerator (1620).

[0309] Additionally, the path controller (1650) can detect at least one of a functional failure of the second protocol converter (1640), a path failure between the first accelerator (1630) and the second protocol converter (1640), a path failure between the second accelerator (1630) and the second protocol converter (1640), or a path failure between the second protocol converter (1640) and the drive control unit (1660). The path controller (1650) can transmit a functional failure signal and a path failure signal to the first accelerator (1620) and the second accelerator (1630). Upon receiving the functional failure signal and the path failure signal, the first accelerator (1620) and the second accelerator (1630) can directly transmit the packet to the drive control unit (1660) if the target device of the input packet is an actuator (1670).

[0310] Additionally, the network subsystem (1600) can detect a functional failure of a computational device (not shown) of the drive control unit (1660). Here, the computational device may be a device including a core that receives command data and calculates a computational result value for driving. When the network subsystem (1600) detects a functional failure of the computational device of the drive control unit (1660), it can transmit a functional failure signal of the computational device to the first accelerator (1620) and the second accelerator (1630). The first accelerator (1620), the second accelerator (1630), and the second protocol converter (1640) that receive the failure signal of the computational device can extract command data (CMD) or a computational result value (DPV) in a predetermined field within an input packet and transmit it to the drive control unit (1660).

[0311] In the present invention, the path through which an Ethernet packet (S2) is transmitted to a drive control unit (1660) via a second accelerator (1630) and a second protocol converter (1640), as shown in FIG. 18, and the path through which a CAN / LIN frame (S1) is transmitted to a drive control unit (1660) via a first accelerator (1620) and a second protocol converter (1640) can be defined as part of the tunneling path.

[0312] FIG. 19 is an internal block diagram of a first zone control unit (17) using register mirroring according to another embodiment of the present invention.

[0313] The MCU subsystem (1720) and the driving control unit (1780) of the first zone control unit (17) of FIG. 19 may calculate a driving operation result value corresponding to the command data or driving operation result value stored in the master register (1715), slave register (1782), and safety register (1770), or generate a driving signal.

[0314] The master register (1715) shown in FIG. 19 may be placed within the memory subsystem (1710) or MCU subsystem (1720), and the slave register (1782) may be placed in the drive control unit (1780).

[0315] A register capable of operating as a master register (1715) is inherent in both the central control unit and the zone control unit, and the master register within the unit that first receives the command signal can be designated as the master register (1715) of the vehicle control system. The designated master register (1715) can transmit data stored within itself to the slave register (1782) of the self-driving control unit (1780) via the network subsystem (1730), and can also transmit to the slave register within another unit via the network subsystem (1730). Here, the other unit refers to the central control unit or the zone control unit connected to it via communication.

[0316] The master register (1715) can store command signals collected from the vehicle, various sensor data of the vehicle (e.g., brake pedal position, speed, steering angle, etc.), command data, and operation result values ​​for driving. The master register (1715) can mirror the stored data to the slave register (1782), and the slave register (1782) can store the data mirrored from the master register (1715). Here, mirroring means writing the same data identically to two memory devices (e.g., registers). Alternatively, mirroring may include the device processing the packet transmitting only a certain portion of the information within the packet to another device when a certain portion of the information within the input packet matches a pre-set reference information.

[0317] For example, if a certain portion of the information in an input packet is related to a drive control unit within a central control unit or a zone control unit, only the operation result value for driving can be extracted from the input packet and mirrored to the drive control unit.

[0318] At least one of the multiple arithmetic units (1721_1, 1721_2 and 1721_3) of the MCU subsystem (1720) generates command data using a command signal when an event occurs—that is, when a command signal is received—and calculates a driving operation result value (e.g., control parameter values ​​for a timer and controller, i.e., prescale value, counter value, comparison value, etc.) using sensor data and command data stored in the master register (1715), and updates the value of a specific address in the master register (1715) and stores it for a certain period. If an error occurs in the arithmetic unit (1781) of the driving control unit (1780), the system manager subsystem (1760) detects this and transmits it to the MCU subsystem (1720), and the MCU subsystem (1720) can mirror the latest driving operation result value stored at a specific address in the master register (1710) to the slave register (1782) of the driving control unit (1780).

[0319] The MCU subsystem (1720), network subsystem (1730), and drive control unit (1780) can refer to data stored in the master register (1715) and slave register (1782) in real time. In particular, the drive control unit (1780) can generate and control a drive signal in conjunction with a command signal, sensor data, command data, or a drive operation result value stored in the master register (1715) and slave register (1782).

[0320] The drive control unit (1780) collects the actuator status from actuators 1 and 2 (1796, 1797) and the electronic control unit (ECU) (1798) and transmits it to the master register (1715) to store the actuator status data, and in subsequent control cycles, the MCU subsystem (1720), the network subsystem (1730), and the drive control unit (1780) can refer to the actuator status data stored in the master register (1715).

[0321] Additionally, the zone control unit (17) may include a safety register (1770). A safety control signal is activated when an error in the arithmetic unit (1781) within the drive control unit (1780), or a value in the master register (1715) or slave register (1782), exceeds a specific threshold. When the MCU subsystem (1720) or the drive control unit (1780) receives the safety control signal, the MCU subsystem (1720) or the drive control unit (1780) can disable the current drive signal, retrieve the safety drive arithmetic result value previously stored in the safety register (1783), generate a drive signal, and transmit it to the corresponding actuator.

[0322] Below is an example of an operation scenario performed in the zone control unit (17) of FIG. 19.

[0323] Changes in data from the vehicle's brake pedal, speed sensor, and steering angle sensor, or driver input (command signal), are collected in real time through the first network subsystem (1730) of the zone control unit (17) (e.g., when the brake pedal is suddenly pressed, the brake pedal sensor detects this and generates a signal, and the speed sensor measures the vehicle's current speed and generates a vehicle's current speed sensing signal).

[0324] The collected signals are converted into data (e.g., input data of the brake pedal, vehicle speed data, command data, etc.) and stored at a specific address in the master register (1715), and the data stored at the specific address in the master register (1715) serves as a central storage and can be updated in real time.

[0325] Data stored at a specific address of the master register (1715) is mirrored through the network subsystem (1730) to a master register or slave register within the zone control unit (17) and the zone control unit (1792, 1794), central control unit (1793), and electronic control unit (ECU) (1795, 1798) connected to the zone control unit (17), and the drive control unit within the zone control unit (1792, 1794), central control unit (1793), and electronic control unit (ECU) (1795, 1798) can retrieve data from the master register or slave register to generate a necessary drive signal.

[0326] In this process, the calculation unit (1781) of the drive control unit (1780) can calculate an appropriate driving calculation result value based on the latest command data stored in the slave register (1782) (e.g., based on the rapid pressure change data of the brake pedal and the current speed of the vehicle, the calculation unit (1781) can calculate control signals such as pulse period and amplitude that generate maximum braking force). A signal generation module (not shown) within the drive control unit (1780) can generate a driving signal using the calculated driving calculation result value and transmit it to the corresponding actuator.

[0327] The network subsystem (1730) can distribute sensor data, command data, and driving operation result values ​​generated in the first zone to each driving device of the vehicle (e.g., brake system, steering system).

[0328] The drive control unit (1780) can collect feedback data (e.g., the braking force actually generated after the brake is applied and the change in vehicle speed, etc.) and transmit it to the master register (1715). The master register (1715) can use the feedback data to adjust the command data received thereafter and the calculated result value for driving, or to adjust other operations of the vehicle control unit and the vehicle control system.

[0329] FIG. 20 is a block diagram showing a detailed internal configuration of a first zone control unit (18) according to another embodiment of the present invention.

[0330] As illustrated in FIG. 20, the first zone control unit (18) may further include a second protocol converter (1839). The second protocol converter (1839) may receive an Ethernet packet or a CAN / LIN frame within a network subsystem (1830), parse and extract command data or driving operation result values ​​for actuators (1896, 1897) directly connected to the first zone control unit (18) from the data field of the packet or frame using hardware or software, and transmit the extracted command data or driving operation result values ​​to the driving control unit (1880) via a B line passing through the main NoC bus system (1870) and the input / output subsystem (1840) or an A line directly connected to the driving control unit (1880) to provide redundancy of the actuator driving signal line.

[0331] At this time, the network subsystem (1830) extracts command data or driving operation result values ​​from an Ethernet packet or a CAN / LIN frame, and if an actuator driving a target device of the extracted command data or driving operation result value is connected to it, it can activate at least one of the plurality of controllers of the input / output subsystem (1840) (see GPSB controller in FIG. 23 and communication controller in FIG. 24) to convert the extracted command data or driving operation result values ​​into a serial communication form and transmit them to the driving control unit (1880).

[0332] If an error occurs in a computational device (not shown) within the drive control unit (1880), the driving computation result value calculated by the MCU subsystem (1820) can be transmitted to the drive control unit (1880) via line A or line B.

[0333] FIG. 21 is a block diagram showing a detailed internal configuration of a first zone control unit (19) according to another embodiment of the present invention.

[0334] In the future, all electronic control units (ECUs) inside the vehicle may be changed to Ethernet electronic control units (ECUs) (1999). Using the 10BASE-T1S controller (1938) shown in FIG. 19, communication can be made individually with the electronic control units (ECUs) (1999) connected to a single bus. Accordingly, the first zone control unit (19) of FIG. 21 is a form in which the first accelerator (1831) and the first protocol converter (1833) are removed from the zone control unit (18) of FIG. 20, so the complexity of the configuration of the first zone control unit (19) can be greatly reduced. In addition, multiple Ethernet electronic control units (ECUs) (1999) can be connected to a single bus, thereby drastically reducing the weight and quantity of existing wire harnesses.

[0335] FIG. 22 is a block diagram of a vehicle control device (20) that generates a signal for driving an actuator according to one embodiment of the present invention.

[0336] The vehicle control unit (20) illustrated in FIG. 22 can generate a signal (2090) for driving an actuator using self-stored manual, assisted, and autonomous driving control algorithms based on at least one of actuator command data, actuator status, actuator surrounding environment, and vehicle surrounding environment information transmitted from a node (2070) of a vehicle network (e.g., electronic control unit (ECU), zone control unit, and central control unit, etc.).

[0337] The vehicle control unit (20) may include a CPU subsystem (2010), an MCU subsystem (2020), a network subsystem (2030), an input / output subsystem (2050), a drive control unit (2060), and a NoC bus system (2040).

[0338] The network subsystem (2030) may include a communication interface (not shown) and a switch (not shown), and can process packets transmitted from a node (2070), namely a central control unit, a zone control unit, and an electronic control unit (ECU) within the vehicle, and transmit them to an adjacent node. The input / output subsystem (2050) may include a plurality of communication controllers (2051, 2052). The input / output subsystem (2050) may provide a function to convert Ethernet communication to serial communication, convert CAN communication to serial communication, and convert LIN communication to serial communication and transmit.

[0339] The CPU subsystem (2010) may include application software including auxiliary and autonomous driving control algorithms.

[0340] The MCU subsystem (2020) is composed of a core capable of high-performance computation and can set the initial state of the vehicle control unit (20).

[0341] The NoC bus system (2040) can control the data flow between the MCU subsystem (2020), the network subsystem (2030), and the input / output subsystem (2050).

[0342] The input / output subsystem (2050) may include two communication controllers (2051, 2052), but is not limited thereto, and may include at least two serial communication controllers (e.g., SPI, I2C, UART, etc.) or at least two CAN communication controllers.

[0343] The drive control unit (2060) may include at least two drive signal generators (2061, 2062), and each of the at least two drive signal generators (2061, 2062) may output the same actuator drive signal for the same input signal. Here, each of the two drive signal generators (2061, 2062) may be configured with a lower performance computing device than the computing device (not shown) in the network subsystem (2030).

[0344] The input / output subsystem (2050) and the NoC bus system (2040) communicate by being connected via a pair of physically separated bus interfaces, and the pair of bus interfaces may include at least one of AHB, AXI, and APB. The number of bus interfaces between the input / output subsystem (2020) and the NoC bus system (2040) may be determined by the number of communication controllers within the input / output subsystem (2050).

[0345] Both of the pair of communication controllers (2051, 2052) of the input / output subsystem (2050) receive at least two identical input signals transmitted from the MCU subsystem (2020) or the network subsystem (2030) and can generate signals converted from both of the at least two identical input signals using the same communication method, or can generate signals converted from at least one of the at least two identical input signals using a different communication method. Here, the input signals are signals transmitted from the node (2070) and may include actuator command data or calculation result values ​​for actuator driving, and the communication methods may include SPI, UART, I2C, and CAN protocols. For example, the first and second communication controllers (2051, 2052) may include one of the pair of SPI communication controllers, the pair of UART communication controllers, the pair of I2C communication controllers, and the pair of CAN controllers. On the other hand, the first and second communication controllers (2051, 2052) may be composed of at least two combinations of an SPI communication controller, a UART communication controller, an I2C communication controller, and a CAN controller. For example, the first and second communication controllers (2051, 2052) may be composed of combinations such as an SPI communication controller and a UART communication controller, an SPI communication controller and an I2C communication controller, a UART communication controller and an I2C communication controller, or an SPI communication controller and a CAN communication controller.

[0346] The network subsystem (2030) can identify command data and driving operation result values ​​for an actuator (2080) directly connected to a vehicle control unit (20) among the data transmitted from the node (2070), and can transmit the command data and driving operation result values ​​for the actuator (2080) to the first and second communication controllers (2051, 2052) through each of a pair of interfaces placed between the NoC bus system (2040) and the input / output subsystem (2050). The first and second communication controllers (2051, 2052) can convert the received command data and driving operation result values ​​for the actuator (2080) into their respective pre-specified communication methods and transmit them to the driving control unit (2060).

[0347] The drive control unit (2060) may include first and second drive signal generators (2061, 2062) and an output unit (2063), and each of the first and second drive signal generators (2061, 2062) may generate an actuator drive signal using command data for the actuator (2080) or a drive operation result value transmitted from the first communication controller (2051) or the second communication controller (2052). Here, the form of the actuator drive signal (2090) may be a PWM signal.

[0348] The output unit (2063) can select one of the actuator driving signals generated by the first and second driving signal generators (2061, 2062) using a logic selection circuit and transmit it to the actuator (2080).

[0349] The output unit (2063) within the drive control unit (2060) monitors the first diagnostic signal (DS1) transmitted from the first communication controller (2051), the second diagnostic signal (DS2) transmitted from the second communication controller (2052), the third diagnostic signal (DS3) transmitted from the first drive signal generator (2061), and the fourth diagnostic signal (DS4) transmitted from the second drive signal generator (2062). When the first to fourth diagnostic signals (DS1 to DS4) are all normal, the output unit (2063) can select and transmit a driving signal generated by the first drive signal generator (2061) or the second drive signal generator (2062) based on the data transmitted from the first communication controller (2051) to the actuator (2080). If an error is detected in any of the first to fourth diagnostic signals (DS1 to DS4), the signal output from the device where the error occurred can be discarded, and a driving signal generated based on the signal output from the normal device can be selected and transmitted to the actuator (2080). By doing so, the path through which the driving signal generated based on the actuator (2080) command data or driving operation result value received from the node (2070) is transmitted to the actuator (2070) is duplicated within the vehicle control device (20), thereby improving the functional safety of the actuator control of the vehicle control device (20). Here, the first and second diagnostic signals (DS1, DS2) may include loopback signals for the first and second communication controllers (2051, 2052).

[0350] Additionally, if an error occurs in the computational device within the first and second driving signal generators (2061, 2062) within the driving control unit (2060), the network subsystem (2030) fetches command data or driving computation result values ​​from a packet passing through the NoC bus system (2040) after the error and transmits them to the MCU subsystem (2020), and the MCU subsystem (2020) can transmit the fetched driving computation result values ​​or driving computation result values ​​calculated from the fetched command data to the driving signal generators (2061, 2062) via the input / output subsystem (2050).

[0351] In the present invention, the path transmitted from the network subsystem (2030) of FIG. 22 to the driving signal generator (2060) is defined as part of the tunneling path.

[0352] FIG. 23 is a block diagram of an input / output subsystem (21) composed of a plurality of GPSB (General Purpose Serial Bus) controllers according to an embodiment of the present invention.

[0353] The input / output subsystem (21) illustrated in FIG. 23 may include at least two GPSB controllers (2140_1 to 2140_3) and a GPIO multiplexer (2160).

[0354] At least two GPSB controllers (2140_1 to 2140_3) of the input / output subsystem (21) are connected to the NoC bus system (2120) via an AXI-AHB interconnect (2130_1) and an AHB-APB interconnect (2130_2) to receive command data (e.g., target operation of a target device, target state, etc.) or driving operation result values ​​(e.g., control parameter values ​​for a timer and controller, prescale values, counter values, comparison values, etc.), convert them into a pre-specified communication method, and transmit them to the driving control unit (2060) of FIG. 22 via a GPIO multiplexer (2160).

[0355] Each of the plurality of GPSB controllers (2140_1 to 2140_3) may include a DMA controller (2141), a buffer (2143), a controller register (2142), an I / O interface (2144), and a loopback diagnostic device (2145). Each of the plurality of GPSB controllers (2140_1 to 2140_3) may operate as a communication controller among SPI (Serial Peripheral Interface), UART, and I2C by changing the configuration and operation of the DMA controller (2141), the buffer (2143), and the I / O interface (2144) using a configuration value for a specific item of the controller register (2142) transmitted from the MCU subsystem (2020) of FIG. 22. Here, specific items may include mode settings (SPI, UART, I2C, CAN modes) and clock settings (e.g., frequency settings, polarity settings, bit width settings, etc.).

[0356] Each of the plurality of GPSB controllers (2140_1 to 2140_3) can operate independently as a master and a slave, so as to transmit an internal signal to the outside or receive an external signal internally, and may further include a loopback diagnostic device (2145) to receive a signal output in the master state as an input signal in the slave state and compare the two signals to diagnose an error in the internal communication path or the communication path between external devices, and output the result as a diagnostic signal (DS1, DS2).

[0357] Each of the plurality of GPSB controllers (2140_1 to 2140_3) has a register set to generate the same output signal for the same input signal, and each of the loopback diagnostic devices (2145) of the plurality of GPSB controllers (2140_1 to 2140_3) can independently diagnose its own internal circuit errors and errors in the communication path between external devices and output diagnostic signals (DIS1, DIS2).

[0358] FIG. 24 is a block diagram of an input / output subsystem (22) according to another embodiment of the present invention.

[0359] The input / output subsystem (22) illustrated in FIG. 24 may include an SPI communication controller (2240), an I2C communication controller (2250), and a GPIO multiplexer (2280). The NoC bus system (2220), the SPI communication controller (2240), and the I2C communication controller (2250) may be connected via an AXI-AHB interconnect (2230_1) and an AHB-APB interconnect (2230_2).

[0360] The SPI communication controller (2240) may largely include a master (2260) and a master virtual slave (2270). The master (2260) may include a configuration control unit (2261) that determines interrupts and transmission frequencies, a command control unit (2262) that converts serial data into parallel data, and a noise filter unit (2263) that removes signal noise. The master virtual slave (2270) may store an output signal transmitted from the master (2260), diagnose a signal error using the stored signal and a loopback circuit, and generate a first diagnosis signal (DS1).

[0361] The I2C communication controller (2250) may separately include an internal loopback circuit, and may diagnose signal errors using the internal loopback circuit and separately generate a second diagnostic signal (DS2). The control parameters of each component of the SPI communication controller (2240) and the I2C communication controller (2250) are respectively set so as to include the same information for the same input signal. That is, when the SPI signal output by the SPI communication controller (2240) for a signal received by the NoC bus system (2220) and the I2C signal output by the I2C communication controller (2250) for a signal identical to the signal received by the NoC bus system (2220) are demodulated, the same command data or the same driving operation result value is generated.

[0362] FIGS. 25 and 26 are block diagrams of a vehicle control system (23, 24) including an electronic control unit (ECU) (2310, 2440, 2450) with improved functional safety of actuator control according to another embodiment of the present invention.

[0363] As illustrated in FIGS. 25 and 26, the vehicle control system (23, 24) may include a zone control unit (2300, 2400) and an electronic control unit (ECU) (2310, 2440, 2450) and may control a plurality of actuators (2360, 2460, 2470, 2480). However, the connection structure and number of zone control units and electronic control units (ECUs) are not limited thereto and may be modified and expanded.

[0364] The zone control unit (2300, 2400) shown in FIGS. 25 and 26 is positioned in a specific zone within the vehicle, and the electronic control unit (ECU) (2310, 2440) can communicate directly with the zone control unit (2300, 2400) and can directly control the actuator (2360, 2460, 2470).

[0365] Each of at least one pair of drive control units (2442 and 2443, 2452 and 2453) within an electronic control unit (ECU) (2440, 2450) may receive data having different information generated from the same command signal, and may perform different processing on the input data having different information to generate the same output signal. Here, the different information may include command data generated from the same command signal for the same target actuator and a driving operation result value calculated from said command data, and the same output signal may be a driving signal in the same pulse form. That is, command data generated for a command signal to lower the driver's window is transmitted to the first drive control unit (2320), and a driving operation result value calculated for a command signal to lower the driver's window is transmitted to the second drive control unit (2330). The first drive control unit (2320) performs an operation on the received command data to calculate a driving operation result value and stores it in the first register (2324). The first drive signal generator (2322) performs processing to generate a driving signal using the first register value and the first clock (not shown). The second drive control unit (2330) stores the received driving operation result value in the second register (2333), and the second drive signal generator (2332) performs processing to generate a driving signal using the second register value and the second clock (not shown). However, the driving signals output from the first drive control unit (2320) and the second drive control unit (2330) are identical.

[0366] The electronic control unit (ECU) (2310, 2440, 2450) illustrated in FIGS. 25 and 26 may include a communication interface (2340, 2441, 2451) composed of at least one of a CAN, LIN, and Ethernet controller, and may include an output unit (2350, 2444, 2454) that outputs a driving signal for directly controlling an actuator (2360, 2460, 2470).

[0367] The first drive control unit (2320) illustrated in FIG. 25 has a first core (2321), but the second drive control unit (2330) may not include a core. The first core (2321) within the first drive control unit (2320) performs an operation on the first command data generated from the first command signal transmitted from the zone control unit (2300) to calculate the first drive operation result value and writes it to the first register (2324), and the first drive signal generator (2322) can generate a drive signal according to the first register value and the first clock (not shown) and transmit it to the actuator (2360) through the output unit (2350). On the other hand, the second drive control unit (2330) writes the first drive operation result value transmitted from the zone control unit (2300) (a value that the first core (2321) must calculate at the time of error occurrence, which is a value calculated by the third calculation device (2301) using the value stored in the master register (2302) of the zone control unit (2300) at the time of error occurrence) and the second drive operation result value (a value calculated by the third calculation device (2301) after the time of error occurrence) to the second register (2333), and the second drive signal generator (2332) can generate a drive signal according to the second register value and the second clock (not shown). Here, the second drive signal generator (2332) has a state machine, a register, and a buffer, and can generate an actuator drive signal according to the register value and the clock signal without a command from the first core (2321).

[0368] The first and second drive control units (2320, 2331) may each be equipped with a monitoring device (2331, 2323) that monitors each other's operations. During normal operation, the first drive control unit (2320) processes data transmitted from the zone control unit (2300), and the monitoring device (2331) of the second drive control unit (2330) can transmit error information to the zone control unit (2300) via a communication interface (2340) if an error occurs in the first core (2321). Here, the error information may include the core ID where the error occurred and the time of the error occurrence.

[0369] The zone control unit (2300) may include a third calculation unit (2301), and the third calculation unit (2301) may calculate a calculation result value for actuator driving using data stored in the master register (2302) within the zone control unit (2400) based on error information transmitted by the first drive control unit (2320), and transmit the result to the electronic control unit (ECU) (2310). The communication interface (2340) within the electronic control unit (ECU) (2310) transmits the received data to the second drive control unit (2330), and the second drive control unit (2330) may generate a signal for actuator driving using the received data and transmit it to the actuator (2360). Subsequently, if the monitoring device (2331) of the second drive control unit (2330) detects that the first core (2321) of the first drive control unit (2320) is operating normally, the second drive control unit (2330) transmits a signal of normal operation of the first core (2321) to the zone control unit (2300), and the zone control unit (2300) can then transmit the received data to the electronic control unit (ECU) (2310). Here, the data may be command data or a result of a driving operation.

[0370] As illustrated in FIG. 26, the zone control unit (2400) may include a drive control unit (2403) capable of directly controlling the third actuator (2480).

[0371] The drive control unit (2403) may have the same structure as the electronic control unit (ECU) (2310) shown in FIG. 25. That is, the drive control unit (2403) within the zone control unit (2400) may include the first and second drive control units (2320, 2331) within the electronic control unit (ECU) (2310) of FIG. 25. That is, when an error occurs in the first drive control unit (2405) of the drive control unit (2403) within the zone control unit (2400), the second drive control unit (2406) may receive data transmitted from the master register (2404), which stores data calculated by the third arithmetic unit (2401), through the second communication interface (2402) and the first communication interface (2404) to generate a drive signal for the third actuator (2408). In this way, the communication interface (2340), output unit (2350), first drive control unit (2320), and second drive control unit (2330) of the first electronic control unit (ECU) (2310) of FIG. 25 are modularized so that they can be used in the same way as the drive control unit (2403) of the zone control unit (2400) of FIG. 26, thereby simplifying the design and shortening the development period.

[0372] FIG. 27 is a block diagram of a vehicle control device (25) that directly controls an actuator in a vehicle according to another embodiment of the present invention.

[0373] As illustrated in FIG. 27, a vehicle control device (25) according to another embodiment of the present invention may include a master register (2500), an MCU subsystem (2510), and a driving signal processing unit (2520), and the driving signal processing unit (2520) may include an input / output subsystem (2530) and a driving control unit (2540).

[0374] The input / output subsystem (2530) may include a first communication controller (2531, 2532) and a second communication controller (2534, 2535), and the first communication controller (2531, 2532) and the second communication controller (2534, 2535) may receive command data or operation result values ​​for driving from the master register (2500). Basically, the first communication controller (2531, 2532) receives command data, and the second communication controller (2534, 2535) may receive operation result values ​​for driving.

[0375] Each of the first communication controller (2531, 2532) and the second communication controller (2534, 2535) of the input / output subsystem (2530) may be configured with at least two serial communication controllers and operated in a redundant manner, and each of the redundant communication controllers may output a signal of the same or different communication method for a single input signal. That is, the same data may be output in one of SPI, UART, and I2C, or in a combination of at least two.

[0376] The drive control unit (2540) may include first and second drive control units (2541, 2555), and the first drive control unit (2541) and the second drive control unit (2555) may receive command data or operation result values ​​for driving from the input / output subsystem (2530). Basically, the first drive control unit (2541) is connected to the first communication controller (2531, 2532), and the second drive control unit (2555) is connected to the second communication controller (2534, 2535), and signals generated by the first and second drive control units (2541, 2555) may be transmitted to the actuator (2580) through the output unit (2559). Here, the first core (2542) may be configured as a dual-core lock-step. Therefore, basically, command data mirrored from the master register (2500) can be converted into a serial communication protocol in the first communication controller (2531) and transmitted to the first drive control unit (2541).

[0377] The first core (2542) of the first drive control unit (2541) of the drive control unit (2540) interprets and calculates command data according to a control model or control algorithm to generate a driving calculation result value and stores it in the first register (2545), and the first drive signal generator (2542) can generate a driving signal using the value of the first register. On the other hand, the second register (2557) of the second drive control unit (2555) stores a driving calculation result value mirrored from the master register (2500), and the second drive signal generator (2558) can generate a driving signal using the value of the second register. That is, the second drive control unit (2555) can generate a driving signal with a processing different from that of the first drive control unit (2541). If an error occurs in the first drive control unit (2541), the second drive control unit (2555) transmits the error of the first drive control unit (2541) to the master register (2500) and the MCU subsystem (2510), and the master register (2500) can transmit data at the time of the error to the input / output subsystem (2530), and the MCU subsystem (2510) obtains command data after the error of the first drive control unit (2541), generates a driving operation result value using the same control model or control algorithm as the first drive control unit (2541), and transmits it to the master register (2500), and the master register (2500) can transmit the updated data to the input / output subsystem (2530).

[0378] The input / output subsystem (2530) may include a GPIO multiplexer (2537), and the GPIO multiplexer (2537) may select and transmit data transmitted from the first and second communication controllers (2531, 2532, 2534, 2535) to the first driving control unit (2541) or the second driving control unit (2555) according to an external control signal.

[0379] Basically, command data transmitted from the master register (2500) can be transmitted to the first driving control unit (2541) via the GPIO multiplexer (2537) through the first communication controller (2531) of the input / output subsystem (2530). If an error occurs in the first communication controller (2531), the first communication controller (2532) can receive the command data transmitted from the master register (2500) by the upper selection signal and transmit it to the first driving control unit (2541) via the GPIO multiplexer (2537). If an error occurs in both the first and first_1 communication controllers (2531, 2532), the second or second_1 communication controller (2534, 2535) can receive data transmitted from the master register (2500) by means of a higher selection signal and transmit it to the first driving control unit (2541) via the GPIO multiplexer (2537). If an error occurs in the first driving control unit (2541), the master register (2500) can transmit the driving operation result value calculated and transmitted by the MCU subsystem (2510) to the second driving control unit (2555) through one of the first or second communication controllers (2531, 2532, 2534, 2535) and the GPIO multiplexer (2537).

[0380] Meanwhile, each controller within the first and second communication controllers (2531, 2532, 2534, 2535) has a loopback diagnostic device (2533, 2536), and the loopback diagnostic signal can be used as an output selection signal at the output unit (2559) of the drive control unit (2540).

[0381] The output unit (2559) may include a logic circuit and can determine a final signal based on the operating status of the first drive control unit and the second drive control unit (2541, 2555) and the loopback diagnostic signal of each of the first and second communication controllers (2531, 2532, 2534, 2535) and transmit it to the actuator (2580).

[0382] FIG. 28 is an internal block diagram of a zone control unit (26) used in a vehicle zone architecture network according to another embodiment of the present invention.

[0383] As illustrated in FIG. 28, the zone control unit (26) may include an MCU subsystem (2600), a memory subsystem (2610), a network device (2620), and a NoC bus system (2630).

[0384] The zone control unit (26) is connected to the target node (TN), and the target node (TN) can be classified into adjacent nodes (AN) and self nodes (SN). The adjacent nodes (AN) may include a central control unit and an adjacent zone control unit, and the self nodes (SN) may include an electronic control unit (ECU) and an actuator that are directly connected to the corresponding zone control unit.

[0385] The NoC bus system (2640) is connected to the MCU subsystem (2600), memory subsystem (2610), and network device (2620) to control the flow of data between these systems and devices.

[0386] The first core (2601) of the MCU subsystem (2600) is composed of a high-performance microprocessor capable of complex calculations and data processing, and can process programs requiring a high amount of computation, Ethernet communication, and large amounts of data. The first core (2601) of the MCU subsystem (2600) prepares a program that can temporarily perform the role of the first core (2542) of the drive control unit (2540) of FIG. 27, and when an error is detected in the first core (2542) of the drive control unit (2540), it can perform the same function as the first core (2542) until the first core (2542) of the drive control unit (2540) recovers from the error.

[0387] The memory subsystem (2610) uses a first memory (2611) used by the first core (2601) of the MCU subsystem (2600) for code execution, data loading, and storage, and a separate memory (not shown) for code execution, data loading, and storage of the second core (not shown) of the network subsystem (2621) and the third core (not shown) of the driving signal processing unit (2622).

[0388] The network subsystem (2621) receives a first signal (protocol format such as Ethernet, CAN, LIN, etc.) input through the network interface (2623), processes it, converts it into a second signal (protocol format such as Ethernet, CAN, LIN, etc.), and transmits it through the network interface (2623). Specifically, the network subsystem (2621) performs the role of an Ethernet switch or router, performs the role of routing CAN and LIN data, and also performs the role of converting received data into heterogeneous data and transmitting it to a destination. For example, the network subsystem (2621) can convert a received Ethernet signal into heterogeneous data such as CAN and LIN and transmit it to a destination. In particular, if the zone control unit itself needs to consume the received data, the network subsystem (2621) can simultaneously transmit the received data to the driving signal processing unit (2622), memory (2611), and MCU subsystem (2600). Here, the data may include command data and a driving operation result value. If an error occurs in the third core of the driving signal processing unit (2622), the driving signal processing unit (2633) transmits to the MCU subsystem (2600) through the second interface (2642), and the first core (2601) of the MCU subsystem (2600) can retrieve the command data or driving operation result value written to the memory (2611) through the DMA controller (2606) and calculate the driving operation result value or the driving signal. The driving operation result value can be transmitted to the driving signal processing unit (2622) through the second interface (2642), and the driving signal can be transmitted to the output unit (2625) using the third interface (2643) and the driving signal switch (2624).

[0389] The network subsystem (2621) can transmit command data transmitted from the central control unit, adjacent zone control unit, and electronic control unit (ECU) to the memory subsystem (2610) and MCU subsystem (2600) through a first interface (2641) connected to the NoC bus system (2640). The driving signal processing unit (2622) can receive driving operation result values ​​transmitted from the MCU subsystem (2600) or memory subsystem (2610) through a second interface (2642) connected to the NoC bus system (2630). Here, the first and second interfaces are electrically and physically separated from each other so that a single point of fail does not occur.

[0390] A network subsystem (2621) processes a first signal (2660) received from an adjacent node (AN) to generate a second signal (2670) or a third signal (2650), and a driving signal processing unit (2622) can receive the third signal (2650) to generate a signal (2680) for driving an actuator. The third signal (2650) may be specific data (e.g., command data or a driving operation result value) extracted through separate parsing from the first signal (2660) when the target node (TN) of the received first signal (2660) is a self-node (SN) and an actuator, or it may be a signal converted from specific data into SPI, UART, and I2C communication. On the other hand, the second signal (2670) is a signal in which specific data of the first signal (2660) is encapsulated in one of the Ethernet, CAN, or LIN protocols when the target node (TN) of the first signal being received is an adjacent node (AN) or is a self node (SN) and an electronic control unit (ECU).

[0391] The network subsystem (2621) and the driving signal processing unit (2622) can be physically isolated and configured to be electrically independent.

[0392] The network subsystem (2621) can perform protocol conversion and data parsing between Ethernet, CAN, and LIN. It may also include processing from Ethernet, CAN, and LIN to SPI / UART / I2C serial communication.

[0393] The first core (2601) of the MCU subsystem (2600) receives command data transmitted from the network subsystem (2621), performs an operation to produce a driving operation result value, and can store the driving operation result value at a specific address of a specific memory of the memory subsystem (2610). Here, the first core (2601) and the third core within the driving signal processing unit (2622) can generate the same driving operation result value for the same command data.

[0394] The network subsystem (2621) can generate a second signal (2670) by processing information (e.g., protocol type, source address, destination address, in-vehicle device ID, etc.) contained in the first signal (2660), and transmit the second signal (2670) to the network interface (2623). Additionally, the network subsystem (2621) can perform security processing on the second signal, such as L2 switching, timestamp, MACsec, and IPsec.

[0395] The third core (not shown) of the driving signal processing unit (2622) can calculate the third signal (2650) transmitted from the network subsystem (2621) to generate a calculation result value for driving the actuator, and use this to generate a signal (2680) for driving the actuator and transmit it to the output unit (2625).

[0396] The network interface (2623) may include a communication interface (e.g., Ethernet PHY, CAN, LIN controller), and the output section (2625) may include a plurality of GPIOs. The network interface (2623) may communicate with a central control unit, an adjacent zone control unit, and an electronic control unit (ECU), and the plurality of GPIOs may be connected to actuators.

[0397] Ethernet-based communication is used between the zone control unit, the central control unit, and adjacent zone control units, and the zone control unit can be connected to the electronic control unit (ECU) via one of Ethernet, CAN, or LIN communication. The zone control unit and the actuator are hardwired to transmit actuator driving signals, such as PWM signals.

[0398] The input signal received by the network device (2620) has data encapsulated in the form of a packet or a frame, and the data includes at least some of command data, a result of a driving operation, an event generating device ID, an in-vehicle device ID that the event generating device ID targets, a network device ID connected to the event generating device, a network device protocol type, an actuator ID connected to the in-vehicle device, a communication protocol of the driving signal processing unit, and a control parameter that determines the form of the driving signal, wherein the event generation may include the generation of a device control signal by a user and the generation of a device control signal by a sensor (see FIG. 41a and FIG. 41b).

[0399] The destination node or zone control unit to which the network subsystem (2621) routes the input signal is automatically identified based on the event generating device ID included in the input signal and may be one of the multiple communication ports of the network interface (2623) or an input terminal (not shown) of the driving signal processing unit (2622) (see FIG. 41a and FIG. 41b).

[0400] The network subsystem (2621) receives a first signal through the network interface (2623), analyzes the first signal, and can transmit it to one of the destination nodes connected to the device to which the first signal is directed.

[0401] The network device (2620) may include a parsing unit (not shown) that derives command data and operation result values ​​for driving from an input signal.

[0402] In the network device (2620), the command data derived can be transmitted to the MCU subsystem (2600) through the first interface (2641), and the driving operation result value derived can be transmitted to the MCU subsystem (2600) or the memory subsystem (2610).

[0403] The memory subsystem (2610) can transmit the stored driving operation result value to the driving signal processing unit (2622) through the second interface (2642) or the third interface (2643) of the NoC bus system (2640).

[0404] FIGS. 29 and FIGS. 30 are internal block diagrams of zone control units (27, 28) used in a zone architecture network within a vehicle, as variations of FIG. 28.

[0405] As illustrated in FIG. 29, the MCU subsystem (2700) receives actuator command data transmitted by the network subsystem (2721) through the first interface (2741) and the NoC bus system (2740), and can directly transmit the result of the operation for driving the actuator calculated by the first core (2701) to the driving signal processing unit (2722) through the NoC bus system (2730) and the second interface (2742).

[0406] The MCU subsystem (2800) illustrated in FIG. 30 receives actuator command data or driving operation result values ​​transmitted by the network subsystem (2821) through the first interface (2841) and the NoC bus system (2840), generates an actuator driving signal, and can directly transmit the generated actuator driving signal to the output unit (2825).

[0407] FIG. 31 is an internal block diagram of a drive control unit (29) according to one embodiment of the present invention.

[0408] The drive control unit (29) illustrated in FIG. 31 may include a GPIO multiplexer (2900), an output unit (2901), a communication interface (2902), a bus interconnect (2903), a computing device (2910), a first drive signal generator (2920), an error detection unit (2930), an identification unit (2940), a clock generator (2950), a communication controller (2960), a second drive signal generator (2970), and an output unit (2980).

[0409] The GPIO multiplexer (2900) can determine the path between GPIO-A to GPIO-D, the output section (2901), and the communication interface (2902). Here, the output section (2901) may include SPI, UART, and I2C communication interfaces, and the communication interface (2902) may include CAN, LIN, and Ethernet interfaces.

[0410] In the third core (2911) of the drive control unit (29), the calculated operation result value for the command data received through the output unit (2901) is stored in the first register (2921) of the first drive signal generator (2920), and the first drive signal generator (2920) can generate a drive signal (e.g., PWM signal) using the operation value for the drive stored in the first register (2921).

[0411] If an error occurs in the third core (2911) of the driving control unit (29), the MCU subsystem of the zone control unit (see FIGS. 28 to 30) fetches command data received at the time of the error and after the time of the error to calculate a driving operation result value, and the calculated driving operation result value is written to the second register (2971) in the second driving signal generator (2970) of the driving control unit (29), and the second driving signal generator (2970) can generate a driving signal using the driving operation result value written to the second register (2971). The output unit (2980) can output the outputs of the first driving signal generator (2920) and the second driving signal generator (2970) using AND logic.

[0412] The communication controller (2960) includes CAN, LIN, and Ethernet communication controllers and can communicate with an external device through a communication interface (2902).

[0413] The arithmetic unit (2910) can interpret command data (including the target device and the target operation and target state of the target device) received through the output unit (2901), determine the identification of the target device and the output target for the actuator driving the target device, calculate control parameter values ​​such as a prescale value, a counter value, and a comparison value required for generating a driving signal that satisfies the output target, and transmit them to the first driving signal generator (2920). The first driving signal generator (2920) can control the amplitude, frequency, and duty cycle of the driving signal using the received control parameter values. Here, the prescale value is a clock division ratio (e.g., 1, 8, 64, 256, 1024, etc.), the comparison value is a value compared by a timer (not shown) (e.g., 8-bit or 16-bit), and the duty cycle is the duration of the High state of the PWM signal. The above control parameter value is stored in the first register (2921) of the first driving signal generator (2920), and the first driving signal generator (2920) can generate a signal for driving an actuator using the parameter value stored in the first register (2921) and transmit it to the output unit (2980).

[0414] The second drive signal generator (2970) is equipped with its own control circuit (state machine, register, buffer) and can read and output bits according to its own clock signal without instructions from the arithmetic unit (2910). The operation method of the second drive signal generator (2970) can be hardware-based and can generate a drive signal according to the set register value and clock signal. That is, the second drive signal generator (2970) can sequentially read data and determine the output signal based on either hardware or software, so the arithmetic unit (2910) does not need to intervene after initial setup. The clock of the second drive signal generator (2970) can be received from the clock generation unit (2950) from the beginning of system operation.

[0415] The output section (2980) is composed of AND logic gates, so that the outputs of the first and second driving signal generators (2920, 2970) can be output through logic such as AND.

[0416] The process of generating and outputting a driving signal by the second driving signal generator (2970) when an error occurs in the third core (2911) within the computing device (2910) is as follows.

[0417] 1) At the beginning of system operation, '0' is stored in the second register (2971) of the second drive signal generator (2970).

[0418] 2) When an error occurs in the third core (2911) of the computing device (2910), the error detection unit (2930) of the driving signal processing unit (29) detects the error.

[0419] 3) The error detection unit (2930) transmits error information (e.g., target actuator ID, time of error occurrence, etc.) to the computational device (2601, 2701, 2801 of FIGS. 28 to 30) of the zone control unit through the output unit (2901).

[0420] 4) The computational device of the Zone control unit receives command data at the time of error occurrence and after the error occurs, calculates a result of computation for driving, and transmits it to the driving control unit (29).

[0421] 5) The identification unit (2940) identifies the driving operation result value for the second driving signal generator (2970) among the signals transmitted from the calculation unit of the zone control unit and writes the value to the second register (2971).

[0422] 6) The state machine and shift register in the second driving signal generator (2970) sequentially read and shift the bits stored in the second register (2971) according to the clock signal received from the clock generator (2950).

[0423] 7) The output buffer (not shown) in the first and second driving signal generators (2920, 2970) determines and outputs 'High' if the read bit value is '1' and 'Low' if the bit value is '0'.

[0424] FIG. 32 is an internal block diagram of a network device (30) within a zone control unit including a path controller (3005) according to another embodiment of the present invention.

[0425] The network device (30) illustrated in FIG. 32 may include a network subsystem (3000) and a drive control unit (3030).

[0426] At least one of a central control unit, a zone control unit, and an electronic control unit (ECU) is connected to a communication interface (3006) (e.g., CAN, LIN, and Ethernet communication interface) of a network subsystem (3000), and can receive packet or frame signals containing command data or operation result values ​​for driving. The network subsystem (3000) can transmit signals to a driving control unit (3030) through GPIOs (3007, 3031).

[0427] A path controller (3005) may be positioned between the first and second accelerators (3002, 3003) and the communication interface (3006). The path controller (3005) may transmit an input packet or frame to the first accelerator (3002), the second accelerator (3003), or the drive control unit (3030) based on a table (3008) in which information of a node transmitting command data, information of a target device, and information of a node including a target device are matched. For example, if the node transmitting command data is a central control unit or a zone control unit, and the target device is a driver's seat window, and the node including an actuator driving the target device is a central control unit, a zone control unit, or an Ethernet electronic control unit (ECU), the path controller (3005) transmits the received packet or frame to the second accelerator (3003). If the node transmitting command data is a central control unit or a zone control unit, the target device is a driver's window, and the node including the actuator driving the target device is a CAN / LIN electronic control unit (ECU), the path controller (3003) transmits the received packet or frame to the first accelerator (3002); and if the node transmitting command data is a central control unit, a zone control unit, or an electronic control unit (ECU), the target device is a driver's window, and the node including the actuator driving the target device is an actuator connected to itself, the path controller (3005) can directly transmit the received packet or frame to the driving signal processing unit (3030) via line A. Additionally, the path controller (3005) can dynamically determine the transmission path of the input packet or frame according to the TSN scheduler and the zone reference table.

[0428] FIGS. 33a and FIGS. 33b are internal block diagrams of a network device (31) within a zone control unit according to another embodiment of the present invention.

[0429] The interface (3130) of the network device (31) illustrated in FIGS. 33a and 33b may include a plurality of communication interfaces (3131 to 3134) and an output unit (3135), and may receive packets or frames from at least one of a central control unit, a zone control unit, and an electronic control unit (ECU).

[0430] The first port (P1) of the first accelerator (3102) of the network subsystem (3100) is connected to the first communication interface (3131), and the first communication interface (3131) can be connected to a specific CAN / LIN electronic control unit (ECU) (3105). The second port (P2) of the first accelerator (3102) is connected to the second communication interface (3132), and the second communication interface (3132) is connected to the GPIO-C of the drive control unit (3170), and the signal transmitted from the second port (P2) of the first accelerator (3102) can be received by the communication controller (3161) through the communication interface (3153) of the drive control unit (3170). Here, the signal transmitted by the second port (P2) of the first accelerator (3102) may be a copy of the signal transmitted by the first port (P1) of the first accelerator (3102).

[0431] The communication controller (3161) of the drive control unit (3170) can receive a signal transmitted from the second port (P2) of the first accelerator (3102) of the network subsystem (3100) and retransmit it to a specific CAN / LIN electronic control unit (ECU) (3105) through the GPIO-B of the drive control unit (3170). That is, the network device (31) can provide a redundant communication path to a specific CAN / LIN electronic control unit (ECU) (3105). If an error occurs in the line between the first port (P1) of the first accelerator (3102) of the network subsystem (3100) and a specific CAN / LIN electronic control unit (ECU) (3105), the communication controller (3161) of the drive control unit (3170) can continue to control the specific CAN / LIN electronic control unit (ECU) (3105) by transmitting a copy signal received through GPIO-C to the specific CAN / LIN electronic control unit (ECU) (3105) through GPIO-B.

[0432] Additionally, the network subsystem (3100) includes a parsing unit (not shown) and a communication controller (not shown) within a second protocol converter (3104). The parsing unit extracts specific data from an input signal received by the network system (3100), and the communication controller converts the specific data into a serial communication protocol and transmits it to an output unit (3135). The output unit (3135) is connected to the GPIO-E of the drive control unit (3170). The first register (3156) within the drive control unit (3170) can store specific data input through the GPIO-E.

[0433] If an error occurs in the path between the first communication interface (3131) and the actuator (3105), the drive control unit (3170) can transmit specific data stored in the first register (3156) to the actuator (3105) through GPIO-B. Here, the specific data may include command data or a result of an operation for driving.

[0434] FIG. 34 is a schematic diagram of a centralized vehicle control system (32) in which an in-vehicle computing device according to another embodiment of the present invention is integrated into a central control unit.

[0435] The central control unit (3200) illustrated in FIG. 34 may be equipped with three high-performance processors (3211 to 3213) of a hypervisor-less structure. Each of the three high-performance processors (3211 to 3213) may run an independent software instance or container to support function redeployment and load balancing in a software-defined vehicle. Each of the three high-performance processors (3211 to 3213) may be responsible for chassis, power train, and body domain control and may be physically isolated structures. The zone control unit (3250) may not include an arithmetic unit capable of interpreting command data to produce a driving operation result value, and may have a driving control unit (3253) that generates a driving signal based on registers.

[0436] FIG. 35 is an internal configuration diagram of a driving control unit (33) of a zone control unit according to another embodiment of the present invention.

[0437] Referring to FIGS. 34 and 35, a central control unit (3200) transmits an Ethernet packet containing command data and a driving operation result value in a specific field to a zone control unit (3250), a network device (3252) within the zone control unit (3250) derives a driving operation result value from the received Ethernet packet, and a driving control unit (3253) can generate a driving signal using the derived driving operation result value. That is, the driving control unit (3253 in FIG. 34, 33 in FIG. 35) can control the first driving signal generator (3320) by writing the received driving operation result value to the first register (3321) of the first driving signal generator (3320) in FIG. 35.

[0438] If the driving operation result value included in the Ethernet packet transmitted by the central control unit (3200) of FIG. 34 is different from the driving operation result value required by the command data, the hidden operation unit (3310) of the driving control unit (3253 in FIG. 34, 33 in FIG. 35) of the network device (3252) can extract the command data included in the Ethernet packet transmitted by the central control unit (3200), calculate the driving operation result value, and write it to the first register (3321) or the second register (3371). Through this, even if a temporary error occurs in the central operation unit (3210), the zone control unit (3250) can continuously control the actuator.

[0439] FIG. 36 is an internal block diagram of a driving signal generator (34) according to a comparative embodiment of the present invention.

[0440] The driving signal generator (34) illustrated in FIG. 36 may include a register (3410), a clock generator (3420), first and second pulse signal generation modules (3430, 3440), and a channel-port mapper (3450).

[0441] The clock generator (3420) can generate a first clock (3421) and a second clock (3422) using an upper system clock signal (3401) and a clock distribution value (3411) provided by a register (3410), and transmit them to a first pulse signal generation module (3430) and a second pulse signal generation module (3440), respectively.

[0442] The first pulse signal generation module (3430) can transmit a first driving signal (3431) to a channel-port mapper (3450) using a first clock (3421) supplied by a clock generator (3420) and a first setting value (3412) provided by a register (3410).

[0443] The second pulse signal generation module (3440) can transmit a second driving signal (3441) to a channel-port mapper (3450) using a second clock (3422) supplied by a clock generator (3420) and a second setting value (3413) provided by a register (3410).

[0444] The register (3410) receives and stores the register value (3403) for each pulse signal generation module from the upper system, and can transmit the stored register value to the first and second pulse signal generation modules (3430, 3440) as the first setting value (3412) and the second setting value (3413), respectively.

[0445] The register value (3403) transmitted by the upper system includes clock distribution values ​​and setting values ​​(configuration values), and the clock distribution value (3411) is transmitted to the clock generator (3420), and the clock generator (3420) can distribute the upper system clock signal (3401) to one of 1 / 2, 1 / 4, or 1 / 8 values ​​using the clock distribution value (3411). The first setting value (3411) and the second setting value (3412) specify the phase mode, register mode, and pattern mode of the first and second pulse signal generation modules (3430, 3440), and can specify the cycle length, signal width within the cycle, number of bits within the cycle, and specific output pattern. The lower system clock signal (3402) is independent of the upper system clock signal (3401) and can transmit the register value of the register (3410) to the first and second pulse signal generation modules (3430, 3440) by the clock signal.

[0446] The driving signal generator (34) of FIG. 36 has the disadvantage that actuator control is stopped even in the event of an error in either the upper system clock signal (3401) or the lower system clock signal (3402). Additionally, it may not provide a register mirroring means for directly controlling the first and second pulse signal generation modules (3430, 3440) from the central control unit or the zone control unit.

[0447] FIG. 37 is an internal block diagram of a driving signal generator (35) according to one embodiment of the present invention.

[0448] The driving signal generator (35) illustrated in FIG. 37 may include a clock interface (3500), a register interface (3510), a register (3520), a clock generator (3530), pulse signal generation modules (3540, 3550), and a channel port mapper (3560).

[0449] The clock interface (3500) can select (3505) one of the first system clock (3501) or the second system clock (3502) and transmit it to the clock generator (3530) and the register (3520). The first system clock (3501) and the second system clock (35020) may have different frequencies, phases, and amplitudes, but preferably may include different frequencies. Here, the first system clock (3501) and the second system clock (3502) may be derived from CLK 1 to CLK 4 of FIG. 13. The clocks derived from each of CLK 1 to CLK 4 may be generated independently without affecting each other. The clock interface (3500) can select at least one of CLK 1 to CLK 4 of FIG. 13 based on whether CLK 1 to CLK 4 of FIG. 13 is operating normally and transmit it to the clock generator (3503).

[0450] The clock generator (3530) can generate at least one clock using a system clock signal (3505) selected and transmitted from the clock interface (3500) and clock distribution values ​​provided by the register (3520), and transmit it to both or only one of the first and second pulse signal generation modules (3540, 3550). Here, among the clock distribution values, the first clock distribution value may be for the first pulse signal generation module (3540), and the second clock distribution value may be for the second pulse signal generation module (3550).

[0451] The register interface (3510) can receive register values ​​(3503) transmitted from the master register (901) of FIG. 11, the CPU subsystem (1100) or MCU subsystem (1120) of FIG. 13, or the master register (1715) of FIG. 19. The register values ​​(3503) may include clock distribution values ​​transmitted to the clock generator (3530), and configuration values ​​for the first pulse signal generation module (3540) and the second pulse signal generation module (3550). Here, the configuration values ​​for the first pulse signal generation module (3540) and the second pulse signal generation module (3550) may include operation result values ​​for actuator driving, and by specifying the phase mode, register mode, and pattern mode, etc., of the first and second pulse signal generation modules (3540, 3550), the cycle length, signal width setting within the cycle, bit number setting within the cycle, and specific output pattern, etc., may be specified. Here, configuration values ​​for the first pulse signal generation module (3540) and the second pulse signal generation module (3550) are received at the register interface (3510) through a plurality of communication controllers (21 or 22) of FIG. 24 and FIG. 25.

[0452] The first pulse signal generation module (3540) can generate a first driving signal using a clock signal transmitted through line 3531 from the clock generator (3530) and at least one of configuration values ​​transmitted through at least one of lines 3522 and 3523 from the register (3520), and transmit it to the channel-port mapper (3560) through line 3541. Here, the first driving signal is an actuator driving signal corresponding to command data.

[0453] The second pulse signal generation module (3550) can generate a first driving signal using a clock signal transmitted through line 3532 from the clock generator (3530) and at least one of configuration values ​​transmitted through at least one of lines 3522 and 3523 from the register (3520), and transmit it to the channel-port mapper (3560) through line 3551. Here, the driving signal generator may include at least two pulse signal generation modules.

[0454] The clock interface (3500) can select one of the first system clock (3501) and the second system clock (3502) depending on whether they are in a normal state, and the register (3520) can transmit a clock distribution value corresponding to the type of signal of the system clock selected by the clock interface (3500) to the clock generator (3530) through at least one of the lines 3521 and 3525.

[0455] In normal operation, the clock interface (3500) transmits the first system clock (3501) to the clock generator (3530), and the clock generator (3530) can generate a first clock signal using the first system clock (3501) and a first clock distribution value transmitted from the register (3520) and transmit it to the first pulse signal generation module (3540). The first pulse signal generation module (3540) can generate a first driving signal (3541) using the first clock signal and a first configuration value transmitted from the register (3520) and transmit it to the actuator through the channel path mapper (3560).

[0456] If an error in the first system clock (3501) is detected, the clock interface (3500) can select the second system clock (3502) and transmit it to the clock generator (3530). The register (3520) can transmit the second clock distribution value to the clock generator (3530). The register (3520) can transmit the first configuration value to the first pulse signal generation module (3540). The clock generator (3530) can generate a first clock signal using the second system clock (3502) and the second clock distribution value (3521) and transmit it to the first pulse signal generation module (3540). The first pulse signal generation module (3540) can generate a first driving signal using the first clock signal and the first configuration value and transmit it to the actuator through the channel path mapper (3560).

[0457] If an error occurs in the signal or line transmitted from the clock generator (3530) to the first pulse signal generation module (3540), the second pulse signal generation module (3550) is activated, and the second pulse signal generation module (3550) A first driving signal can be generated using a first clock signal transmitted from a clock generator (3530) and a first configuration value transmitted from a register (3520). Here, the first and second pulse signal generation modules (3540, 3550) are identical in terms of operating frequency, circuit configuration, and clock generation method. If the first and second pulse signal generation modules (3540, 3550) are not identical in terms of operating frequency, circuit configuration, and clock generation method, the register (3520) transmits a second configuration value to the second pulse signal generation module (3550), and the second pulse signal generation module (3550) can generate a first driving signal using the first clock signal and the second configuration value.

[0458] If an error occurs in the signal or line transmitted from the clock generator (3530) to the first pulse signal generation module (3540) and an error also occurs in the first system clock (3501), the clock generator (3530) can receive a second clock distribution value from the register (3520) to generate a first clock signal, and the second pulse signal generation module (3550) can generate a first driving signal using the first clock signal and the second configuration value.

[0459] Meanwhile, the register (3520) separately contains a safety control value, and when the actuator exceeds the state required by the command data (e.g., rapid acceleration, rapid window rise, rapid turn, etc.), the register (3510) receives an error signal (AF) from a device (not shown) that monitors the actuator state, and the register (3510) transmits the safety control value to the first and second pulse signal generation modules (3540, 3550) via line 3524, and the first and second pulse signal generation modules (3540, 3550) process the safety control value with the highest priority to stop the actuator or maintain it in a safe state.

[0460] Additionally, in the case of an emergency control signal, the upper system transmits a direct control signal (DCS) to the register interface (3510), and the register interface (3510) can transmit the received register value (3503) after receiving the direct control signal (DCS) directly to the first or second signal generation module (3540, 3550) through line 3511. Here, the upper system may include the CPU subsystem (1000, 2010), MCU subsystem (1020, 1820, 1920, 2020, 2600, 2700, 2800), and central processing unit (3210) of FIGS. 13, FIGS. 14, FIGS. 15, FIGS. 20, FIGS. 21, FIGS. 28, FIGS. 29, FIGS. 30, and FIGS. 34. Here, the register value (3503) may include a calculation result value for driving an actuator. Here, the direct control signal (DCS) may be a selection signal transmitted to directly control the first and second pulse signal generation modules (3540, 3550) from the central control unit or the zone control unit.

[0461] On the other hand, the second pulse signal generation module (3550) operates in complementary manner with the first pulse signal generation module (3540) and can be used for precise control of the actuator. That is, the second pulse signal generation module (3550) can transmit an auxiliary driving signal of the first pulse signal generation module (3550).

[0462] That is, both the first pulse signal generation module (3540) and the second pulse signal generation module (3550) are activated, and the clock generator (3530) can receive the third clock distribution value through line 3525 to generate the second clock signal and transmit it to the second pulse signal generation module (3550) through line 3532. The first pulse signal generation module (3540) generates a main driving signal, and the second pulse signal generation module (3550) receives a separate configuration value (3523) from the register (3520) to generate an auxiliary driving signal, and the actuator can be precisely controlled by a combination of the main driving signal and the auxiliary driving signal. Here, the auxiliary driving signal may be a pre-set calculation result value for driving the actuator corresponding to the configuration value stored for each address of the register (3520). Alternatively, it may be a calculation result value for driving the actuator transmitted by another control device other than the device currently transmitting the actuator driving command signal. That is, when the driver transmits a brake pedal signal and simultaneously an additional brake signal transmitted by the ADAS system is generated, the second pulse signal generation module (3550) can generate a driving signal corresponding to the additional brake signal and transmit it to the actuator.

[0463] Here, the configuration value and the calculation result value for actuator driving may be parameters for setting the period, signal, width, pattern, etc. of the actuator driving signal generated by the first and second pulse signal generation modules (3540, 3550).

[0464] The register interface (3510) can write the input register value (3503) to a specific address of the register (3520) when a write signal (WS) is received from the upper system.

[0465] The driving signal generator (35) can avoid stopping the driving signal generator (35) due to a failure of the clock signal by using at least one of the first system clock (3501) and the second system clock (3502) signals.

[0466] In the present invention, the path between the register interface (3510) and the register (3520), as shown in FIG. 37, can be defined as part of the tunneling path.

[0467] FIG. 38 is a diagram showing the signal flow in a zone control system (36) having a data security and backup path according to another embodiment of the present invention.

[0468] The zone control system (36) illustrated in FIG. 38 may include first to fourth zone control units (3610, 3611, 3612, and 3613). The configuration of FIG. 38 is one embodiment, and variations in the number of zone control units and the network architecture are possible.

[0469] FIG. 38 shows the signal contents of each component and transmission path of the zone control system (36) when actuator command data (CMD(t0)) is received by the first zone control unit (3610) and the actuator (3620) driving the target device directed by the actuator command data (CMD(t0)) is in the third zone control unit (3612). Here, the actuator command data (CMD(t0)) may be input to any one of the first to fourth zone control units (3610 to 3613).

[0470] At time T0, actuator command data (CMD) is input to the first zone control unit (3610).

[0471] During the time T0 to T1, the first zone control unit (3610) calculates a first driving calculation result value (DPV1) for actuator command data (CMD) by its own calculation unit.

[0472] At time T1, the first zone control unit (3610) transmits the original of the actuator command data (CMD) and the original of the first driving operation result value (DPV1) to the second zone control unit (3611), and after a certain time (t1+a), transmits a copy of the actuator command data (CMD') and a copy of the first driving operation result value (DPV1') to the fourth zone control unit (3613).

[0473] During the time T1 to T2, the second zone control unit (3611) generates a second driving operation result value (DPV2) by its own calculation device using the source of the actuator command data (CMD) transmitted from the first zone control unit (3610), and selects one of the first driving operation result value (DPV1) or the second driving operation result value (DPV2) (DPV_A) through a predetermined rule (e.g., 2oo3 or 3oo5 voting logic, etc.) using the source of the generated second driving operation result value (DPV2) and the first driving operation result value (DPV1) transmitted from the first zone control unit (3610), and if they are not the same, selects both the first driving operation result value (DPV1) and the second driving operation result value (DPV2) and prepares for transmission. Here, if the first driving operation result value (DPV1) and the second driving operation result value (DPV2) are not the same, the first alarm signal (A) can be transmitted to the central control unit (3600). The central control unit (3600) can receive and store or perform operation processing of at least one of CMD (t0) and DPV1 (t0~t1), and upon receiving the first alarm signal (A1), prepares to transmit at least one of CMD (t0) and its own operation processing result value to the third zone control unit (3612).

[0474] During the time T1+a to T2+a, the fourth zone control unit (3613) generates a fourth driving operation result value (DPV4) by its own calculation device using a copy (CMD') of the actuator command data transmitted from the first zone control unit (3610), and selects either the copy (DPV1') of the first driving operation result value or the fourth driving operation result value (DPV4) through a predetermined rule based on the generated fourth driving operation result value (DPV4) and the copy (DPV1') of the first driving operation result value transmitted from the first zone control unit (3610). If they are not identical, it selects both the copy (DPV1') of the first driving operation result value and the fourth driving operation result value (DPV4) and prepares for transmission. Here, if both the copy of the first driving operation value (DPV1') and the fourth driving operation result value (DPV4) are not identical, the second alarm signal (A2) can be transmitted to the central control unit (3600). When the central control unit (3600) receives the second alarm signal (A2), it prepares to transmit at least one of the CMD (t0) and its own operation processing result to the third zone control unit (3612).

[0475] At time T2, the second zone control unit (3611) transmits the original actuator command data (CMD) and DPV_A to the third zone control unit (3612).

[0476] At time T2+a, the fourth zone control unit (3613) transmits a copy of the actuator command data (CMD') and the selected driving operation result value (DPV_B) among DPV1 and DPV4 to the third zone control unit (3612).

[0477] During the time T2+a to T3, the third zone control unit (3612) selects one of the actuator command data (CMD) source and copy (CMD') according to a predetermined rule (802.1CB standard specification) and calculates the third driving operation result value (DPV3) using the selected signal.

[0478] At time T3, the third zone control unit (3612) compares the values ​​of DPV_A, DPV_B, and DPV3, and if two or more of the three are identical, selects one of the identical two, or if three or more of the five are identical, finally selects one of the identical three (DPV_F), and generates a driving signal (DS) using the initially selected operation result value (DPV)F) and transmits it to the target actuator (3620). If the received signals differ by more than a predetermined number (e.g., two or more of three or three or more of five), the third zone control unit (3612) can transmit a third alarm signal (A3) to the central control unit (3600).

[0479] When the central control unit (3600) receives the third alarm signal (A3), it can transmit the CMD and the self-calculated result value (DPV5) to the third zone control unit (3612). Additionally, if the signal in DPV_A, the signal in DPV_B, and the DPV3 signal are all different, the third zone control unit (3612) transmits a separate alarm signal to the central control unit (3600), the central control unit (3600) transmits DPV5 to the third zone control unit (3612), and the third zone control unit (3612) can generate a driving signal (DS) using DPV5. Alternatively, the third zone control unit (3612) can control the target actuator (3620) to a predetermined safety state.

[0480] The zone control system (36) within the vehicle illustrated in FIG. 38 can generate a driving signal using an error-free driving calculation result value and transmit it to a target actuator by having each zone control unit perform calculations on the same command data and transmit the calculated value to the next zone control unit, and the next zone control unit compares and verifies the accumulated calculated value, selects only the reliable value, and transmits it to the next zone control unit.

[0481] Through this, the zone control system (36) of the present invention can accurately transmit a driving calculation result value that accurately corresponds to the initial command data to the actuator driving the target device even if data manipulation due to external intrusion or an error in the calculation device within the unit occurs, and additionally, if the driving calculation result value is uncertain or not resolved, the zone control system (36) can control the target actuator at a pre-set safety level.

[0482] Meanwhile, the central control unit (3600) of the zone control system (36) of FIG. 38 may provide a means to check for errors in a computation device or path within each zone control system (36) by applying a predetermined rule using alarm signals transmitted by the first, second, and fourth local control units (3610, 3611, 3613) and their respective self-computation values ​​(first computation value, second computation value, fourth computation value).

[0483] For example, if the central control unit (3600) receives an alarm signal from the second zone control unit (3611) but does not receive an alarm signal from the fourth zone control unit (3613), the central control unit (3600) can recognize that an error has occurred in the computational device of the second zone control unit (3611) or in the path between the first zone control unit (3511) and the second zone control unit (3611) and perform post-processing. If an alarm signal is received from both the second zone control unit (3611) and the fourth zone control unit (3613), the central control unit (3600) can compare the self-computation values ​​transmitted by the second zone control unit (3611) and the fourth zone control unit (3613), and if they are the same, identify that there is an error in the computational device within the first zone control unit (3610).

[0484] As another example, if the self-calculated value transmitted by the first, second, and fourth zone control units (3610, 3611, 3613) of the central control unit (3600) is all the same, and the self-calculated value (DPV3) of the third zone control unit (3612) is different from the self-calculated values ​​(DPV1, DPV2, DPV4) transmitted by the first, second, and fourth zone control units (3610, 3611, 3613), the central control unit (3600) may select one of DPV1, DPV2, and DPV4 and write it to a register within the drive control unit of the third zone control unit (3612). Alternatively, the second zone control unit (3611) may write the self-calculated result value (DPV2) to a register within the drive control unit of the third zone control unit (3612).

[0485] FIG. 39 is a block diagram of a zone control unit (37) constituting the zone control system (36) of FIG. 38 according to another embodiment of the present invention.

[0486] The zone control unit (37) shown in FIG. 39 is an internal block diagram of the third zone control unit (3613) shown in FIG. 38. However, the internal block diagram of FIG. 39 can be applied commonly to the first to fourth zone control units (3610, 3611, 3612, 3613).

[0487] The zone control unit (37) may include a network subsystem (3700), a computing unit (3710), and a driving control unit (3720).

[0488] A network subsystem (3700) within a zone control unit (37) can transmit a signal including at least one of command data (CMD), a driving calculation result value (DPV_E) calculated by its own computing unit, driving calculation result values ​​(DPV_J) calculated and transmitted by an adjacent zone control unit, and an alarm signal (A) (an alarm signal transmitted by a computing unit (3710) within the zone control unit (37)) through a plurality of signal lines l1 to a computing unit (3710) within the zone control unit (37), an adjacent zone control unit, a central control unit, and an electronic control unit (ECU) (3750) outside the zone control unit (37).

[0489] The network subsystem (3700) can create a copy of the original of the command data or the result of the operation for driving and transmit the original and the copy to an adjacent zone control device at regular intervals.

[0490] Specifically, the computing device (3710) within the zone control unit (37) can calculate its own calculated value (DPV_E) using command data (CMD) received from the network subsystem (3700) via signal line l4, and transmit the calculated DPV_E to the network subsystem (3700) via signal line l2.

[0491] Additionally, the network subsystem (3700) within the zone control unit (37) selects one of the original and a copy of the command data received at regular intervals according to the 801.1CB standard, and the computing unit (3710) verifies the integrity of the data by applying a predetermined first rule (e.g., bit comparison in a specific cycle interval) to the selected command data, and can transmit an alarm signal indicating an error on the network path to the outside through the network subsystem (3700) in the event of an anomaly.

[0492] Additionally, the computational device (3710) within the zone control unit (37) can determine a final computational value (DPV_F) by applying a second rule (e.g., 2oo3 or 3oo5 decision logic) to at least one driving computational result value (DPV_J) transmitted from an adjacent zone control unit and a driving computational result value (DPV_E) that is self-calculated, and transmit it to the network subsystem (3700) through signal line l3.

[0493] The network subsystem (3700) can transmit the final calculated value (DPV_F) to the drive control unit (3720) via signal line l5. Here, when the calculation unit (3710) compares its own calculated value (DPV_E) with the calculated values ​​(DPV_J) transmitted by other zone control units, if a difference of more than a predetermined number occurs, it generates an alarm signal (A) indicating an error in the calculation unit (371) within the vehicle control system and transmits it to the network subsystem (3700) via signal line l3. The network subsystem (3700) can then transmit the alarm signal (A) to the central control unit or adjacent zone control units via multiple signal lines l1. Here, signal lines l2, l3, and l4 may be composed of a single signal line.

[0494] Additionally, the computing device (3710) can transmit command data or a computational value directly to the drive control unit (3720) via signal line l7 when the actuator to which the command data input to the network subsystem (3700) is directed is the actuator (3760) connected to it.

[0495] The network subsystem (3700) transmits the received command data (CMD) to the electronic control unit (ECU) (3750) via signal line l6, and the electronic control unit (ECU) (3750) can generate a driving signal (DS2) using the command data (CMD) and transmit it to the second actuator (3770).

[0496] The drive control unit (3720) writes the final operation value (DPV_F) transmitted from the network subsystem (3700) through signal line l5 to a specific address of the register (3721) via the communication interface (3733), and the drive signal generation module (3722) can generate a drive signal (DS1) using the register value written to the specific address and transmit it to the first actuator (3760).

[0497] That is, the computation device (3710) of FIG. 39 collects data (e.g., sensor data, command data, driving computation result value, etc.) transmitted by the adjacent zone control unit, calculates its own computation value (DPV_E) using the collected data, filters out error data by comparing the self-calculated computation value (DPV_E) with the computation value (DPV_J) transmitted by the adjacent zone control unit, selects data of integrity, and transmits it to the network subsystem (3700), and the driving control unit (3720) stores the final integrity data transmitted by the network subsystem (3700) in the register (3721) when it is identified as its own, and the driving signal generation module (3722) can generate a driving signal using the data stored in the register (3721).

[0498] FIG. 40 is a configuration diagram of a vehicle control system (38) which is another embodiment of the present invention.

[0499] FIG. 40 is a drawing for explaining FIG. 41a, 41b, 42 and 43. All network devices of the central control unit (3850), the first, second, and fourth zone control units (3810, 3820, 3840) and the electronic control unit (ECU) (3812) of FIG. 40 may be configured to be identical to the third network device (3831) having the third driving signal processing unit (3832) of the third zone control unit (3830).

[0500] The first user operation unit (3860) (event generating device ID: 0001) of FIG. 40 is connected to the first network device (3811) (network device ID: 0001) within the first zone control unit (3810), and the second user operation unit (3861) (event generating device ID: 0010) can be connected to the fifth network device (3813) (network device ID: 0101) within the electronic control unit (ECU) (3812). Here, the user operation units (3860, 3861) may include in-vehicle switches, clusters, and in-vehicle sensor devices.

[0501] The third zone control unit (3830) may be placed in the third network device (3831) (network device ID: 0011) and the third drive signal processing unit (3832) (drive signal processing unit ID: 0011).

[0502] FIG. 40 shows a structure in which a rear seat window (3880) (vehicle device ID: 0001) is connected to a third actuator (3870) (actuator ID: 0011), and the third actuator (3870) is connected to a third drive signal processing unit (3832). Additionally, the register (3833) of the third drive signal processing unit (3832) may have a write address set to 0x000C.

[0503] The first user control unit (3860) is, for example, a switch that controls the rear left window (3880) as one of the switches next to the driver's seat, and the second user control unit (3861) is, for example, one of the controls inside the vehicle and can likely control the rear left window (3880).

[0504] FIGS. 41a and FIGS. 41b are drawings showing a frame (3900) generated by a vehicle control system to directly control an actuator according to one embodiment of the present invention.

[0505] The description in FIGS. 41a and FIGS. 41b is based on the configuration of the vehicle control system (38) of FIGS. 40.

[0506] In the event of an emergency situation (e.g., inability to control the actuator) in the vehicle network, the vehicle control system (38) of FIG. 40 requires a means to directly control the actuator to a safe value.

[0507] The frame (3900) of FIG. 41a and FIG. 41b generated by the network device (3811, 3821, 3831, 3841, 3813) of FIG. 40 may include an event generating device ID (3901), an in-vehicle device ID (3902), a network device ID (3903) connected to the event generating device, a communication protocol (3904) of the network device, an actuator ID (3905) connected to the in-vehicle device, a driving signal processing unit ID (3906) connected to the actuator, a communication protocol (3907) of the driving signal processing unit, and register information (3908).

[0508] Network devices (3811, 3821, 3831, 3841, 3813 of FIG. 40) can automatically generate frames (3900) of FIG. 41a and FIG. 41b using pre-written event reference tables (3910), network device reference tables (3920), in-vehicle device reference tables (3930), actuator reference tables (3940), and driving signal processing unit reference tables (3950) based on devices that generate events (e.g., user control units that generate operation signals for in-vehicle devices and domains that generate control signals related to steering, braking, and driving) and nodes that first receive events and transmit them as packets. The plurality of reference tables can be stored in the memory of each network device (3811, 3821, 3831, 3841, 3813 of FIG. 40). Multiple reference tables may include zone reference tables that match physical zones with zone control units.

[0509] The event reference table (3910) is composed of an event generating device ID - an in-vehicle device ID - and a network device ID connected to the event generating device, and can provide ID information of the final target device that the event generating device aims for and the network connected to the final target device; the network device reference table (3920) is composed of a network device name - a network device ID - and a communication protocol, and can provide information on the type of communication protocol for each network device; the in-vehicle device reference table (3930) is composed of an in-vehicle device ID - and an actuator ID connected to the in-vehicle device, and can provide ID information of the actuator connected to each in-vehicle device; the actuator reference table (3940) is composed of an actuator ID - and a driving signal processing unit ID connected to the actuator, and can provide driving signal processing unit ID information for each actuator; and the driving signal processing unit reference table (3950) is composed of a driving signal processing unit name - ID - a communication protocol - a write address - a clock distribution value - the number of signals per cycle, etc., and can provide information on the communication protocol, write address, and control parameters (driving operation result) of the driving signal for each driving signal processing unit. It can provide information on the value.

[0510] In this way, the network device (3811, 3821, 3831, 3841, 3813 of FIG. 40) can automatically generate the frame based on its own information and identification information of the user operation unit or domain.

[0511] The clock distribution value (3951) and the number of signals per cycle (3952) in the drive signal processing unit reference table (3950) are actuator drive operation result values ​​calculated by an arithmetic unit (not shown) in the zone control unit (3810, 3820, 3840), and can be written to a specific address of the register (3833) of the drive signal processing unit (3832) of FIG. 39. Additionally, the register information (3908) may further include command data and a write address derived from the event generating device ID (3901).

[0512] In this way, when the ID of the user control unit (3860, 3861) where the event signal is generated and the network device that first receives the event signal are identified, the frame (3900) or payload of FIG. 41a and FIG. 41b is automatically generated in at least one of the zone control units (3810, 3820, 3830, 3840) of FIG. 40, and the automatically generated frame (3900) or payload is broadcast to all of the zone control units (3810, 3820, 3830, 3840) of FIG. 40, and the network devices of all of the zone control units (3810, 3820, 3830, 3840) can decapsulate the automatically generated frame (3900) and transmit it to their own driving signal processing unit (3832) or to an adjacent network device.

[0513] FIGS. 42 and FIGS. 43 are flowcharts of a vehicle control system according to one embodiment of the present invention controlling an actuator using a frame (3900).

[0514] The flowcharts of FIGS. 42 and 43 are based on the configuration of the vehicle control system (38) and frame (39) shown in FIGS. 40, 41a and 41b.

[0515] First, the network device that first receives the event automatically generates a first frame (3900) through the device information (identification ID) that generated the event and a plurality of reference tables (3910, 3920, 3930, 3940, 3950) (step S4000). Here, the event includes a user operation signal or a control signal generated in a steering, brake, or driving system, and the generated first frame (3900) may include command data showing the content of the event and a driving operation result value calculated by itself using the command data.

[0516] Afterward, the network device extracts the driving signal processing unit ID in the fifth field of the first frame (3900) and checks whether the derived driving signal processing unit is a driving signal processing unit connected to itself (step S4010).

[0517] If the network device is a drive signal processing unit connected to itself, it extracts only the register information (3908) from the first frame (3900) (step S4020). Here, the network device can verify the integrity of the register information (3980) by comparing the extracted register information (3980) with a plurality of reference table information stored within itself. If a problem occurs with the integrity of the register information (3980), an alarm is transmitted to the central control unit, and the central control unit can determine the signal transmission path to the final target actuator and the register information to be transmitted based on the alarm signal transmitted from the in-vehicle zone control unit, the register information, and its own calculated value. Meanwhile, the plurality of reference tables can be downloaded and updated by the central control unit or via OTA.

[0518] Next, the network device determines the signal conversion form to be transmitted from the network device to its own driving signal processing unit by using the communication protocol information (3904) of the network device in the third field of the first frame (3900) and the communication protocol information (3907) of the driving signal processing unit in the sixth field (step S4030). This allows the signal conversion in the network device to be performed quickly. The signal conversion forms may include conversion to Ethernet-serial communication, CAN-serial communication, and LIN-serial communication.

[0519] Next, the network device transmits the extracted register value (3908) and register write address information to a self-driving signal processing unit through one of the signal conversion forms of the above communication method (step S4040).

[0520] The self-driving signal processing unit stores the received register value (3908) in a write address within the register and uses the stored register value (3908) to generate a driving signal and transmits it to an actuator connected to the self-driving signal processing unit (step S4050).

[0521] If the driving signal processing unit (3906) in the fifth field of the first frame (3900) is not a driving signal processing unit connected to itself, the network device (3811) generates a second frame by converting the third field (3904) of the first frame (3900) into its own communication protocol (step S4060).

[0522] The network device (3811) determines the protocol conversion type using the communication protocol of the third field (3904) before the change and the communication protocol information after the change, and transmits the protocol-changed second frame to the adjacent zone control unit (S4070). Here, the protocol conversion may include one of Ethernet-Ethernet, Ethernet-CAN, Ethernet-LIN, CAN-LIN, CAN-CAN, and LIN-LIN conversions.

[0523] Next, the network device of the adjacent zone control unit receiving the second frame proceeds to step S4010.

[0524] Accordingly, by using the network device and driving signal processing unit that generate the frame (3900) and process data using the frame (3900) of the present invention, the end-to-end time delay can be reduced by extracting and using only the information necessary for rapid protocol conversion and target actuator driving.

[0525] The features of the embodiments and aspects described above may be combined, provided that the combination thereof does not result in obvious technical conflicts. Explanation of the symbols

[0526] 1: Vehicle Network 1-1, 2-1, 2-2, 2-3, 2-4, 3, 4, 5, 6, 7-1, 7-2, 800, 9, 14, 23, 24, 25, 32, 36, 38: Vehicle Control System 10, 11, 100, 160, 200, 200_2, 400, 500, 630, 740-1, 740-2, 830, 900, 1293, 1393, 1793, 1893, 1993, 3200, 3600, 3850: Central Control Unit 12, 13, 17, 18, 19, 26, 27, 28, 37, 110, 120, 130, 140, 150, 170, 210, 220, 230, 240, 210_1, 220_1, 230_1, 240_1, 210_2, 220_2, 230_2, 240_2, 210_3, 220_3, 230_3, 240_3, 410, 420, 430, 440, 530, 600, 620, 700-1, 700-2, 730-1, 730-2, 840, 910, 920, 1091, 1092, 1093, 1094, 1191, 1192, 1193, 1194, 1292, 1294, 1392, 1394, 1792, 1794, 1892, 1894, 1992, 1994, 1400, 2300, 2400: Zone Control Unit 111, 121, 131, 141, 180, 250, 250_1, 250_2, 250_3, 260, 260_1, 260_2, 260_3, 270, 270_1, 270_2, 270_3, 280, 280_1, 280_2, 280_1, 280_3, 401, 410, 411, 412, 421, 431, 441, 610, 720-1, 720-2, 933, 940, 951, 952, 1090, 1190, 1290, 1291, 1390, 1391, 1395, 1398, 1399, 1430, 1440, 1790, 1791, 1795, 1798, 1799, 1890, 1891, 1898, 1899, 1995, 1998, 1999, 2310, 2440, 3260, 3750, 3812: Electronic Control Unit (ECU) (Electric Control Unit) 123, 133, 143, 156, 290, 331. 332, 640, 750-1, 750-2, 860, 930, 932, 941, 942, 1196, 1197, 1296, 1297, 1396, 1397, 1450, 1460, 1470, 1670, 1796, 1797, 1896, 1897, 1996, 1997, 2080, 2360, 2460, 2470, 2480, 2580, 3270, 3760, 3770, 3870: Actuator 16, 30, 31, 811, 2620, 2720, 2820, 3252, 3811, 3813, 3821, 3831, 3841: Network apparatus 20, 800, 1400: Vehicle control apparatus 201, 201_1, 201_2, 1000, 1100, 3210: Central processing device 202: Central Gateway 211, 221, 231, 241: L2 / L3 Switch 961, 962, 931, 943: Sensor unit 1012, 1112, 1212, 1312, 1712, 1812, 1912: Deep Packet Inspection (DPI) 1011, 1111, 1211, 1311, 1711, 1732, 1811, 1911, 2110, 2141, 2210: DMA (Direct Memory Access) 1013, 1113, 1213, 1313, 1603, 1604, 1713, 1813, 1913, 2611, 2711, 2811: Memory 2612, 2712, 2812: Memory Controller 2723: Network Interface 1050, 1150, 1250, 1350, 1750, 1850, 1950: Security sub system 1060, 1160, 1260, 1360, 1760, 1860, 1960: System Manager subsystem 1735: 10BASE-T1S Controller 29, 33, 707-1, 707-2, 1180, 1280, 1380, 1660, 1780, 1880, 1980, 2060, 2320, 2330, 2405, 2406, 2442, 2443, 2452, 2453, 2540, 2541, 2555, 3030, 3170, 3253, 3720: Driving Control Unit 320, 321, 322, 323, 324, 812, 914, 924, 1420, 2520, 2622, 2722, 2822, 3000, 3832: Driving Signal Processing Unit 34, 35, 213, 223, 233, 243, 252, 262, 272, 282, 2061, 2062, 2322, 2332, 2543, 2558, 2920, 2980, 3157, 3320, 3370, 3722: Driving Signal Generation Device 709-1, 712-2, 3430, 3440, 3540, 3550, 3722: Pulse Signal Generation Module 15, 505, 531, 603, 703-1, 703-2, 811, 913, 921, 1030, 1130, 1230, 1330, 1600, 1730, 1830, 1930, 2030, 2621, 2721, 2821, 3000, 3100, 3700: Network sub system 2623, 2723, 2823: Network Interface 2624: Driving signal switch 2144, 3101, 3301: Input / Output Interface 2901, 3032, 3101, 3301: Serial communication interface 2340, 2902, 3006, 3033, 3131, 3132, 3133, 3134, 3153, 3302: Communication interface 2930: Fail Detect Unit 3158, 3330: Fail Management Unit 2940: Identification unit 915, 925, 1070, 1170, 1270, 1370, 1770, 1870, 1970, 2040, 2120, 2220, 2640, 2740, 2840, 2903: NoC bus system 503, 532, 562, 601, 701-1, 701-2, 912, 922, 1020, 1120, 1220, 1320, 1720, 1820, 1920, 2020, 2100, 2200, 2510, 2600, 2700, 2800: MCU subsystem 501, 1000, 1100, 2010: CPU sub system 506, 534, 564, 604, 704-1, 704-2, 911, 923, 1010, 1110, 1210, 1310, 1710, 1810, 1910, 2601, 2610, 2711, 2710, 2810, 3251: Memory sub system 21, 22, 705-1, 705-2, 1040, 1140, 1240, 1340, 1740, 1840, 1940, 2050, 2530: Input / Output Sub System 1031, 1131, 1231, 1331, 1520, 1620, 1731, 1831, 3002, 3102: First accelerator 1035, 1135, 1235, 1335, 1530, 1630, 1738, 1838, 1935, 3003, 3103: second accelerator 1033, 1133, 1233, 1333, 1410, 1733: protocol converter 1510, 1610, 1833, 3001, 3101: first protocol converter 1640, 1839, 1939, 3004, 3104: second protocol converter 901, 1715, 2302, 2404, 2500: Master register 708-2, 709-2, 916, 926, 1381, 1782, 2324, 2333, 2545, 2557, 2921, 2971, 3156, 3164, 3321, 3371, 3721, 3833: Slave register 2142: Communication controller register 3410, 3520: Driving Signal Generator register 3500: Clock Interface 3510: Register Interface 212, 211_1, 222, 222_1, 232, 232_1, 242, 242_1, 251, 261, 271, 281, 502, 504, 533, 563, 602, 702-1, 702-2, 816, 1781, 2301, 2321, 2333, 2401, 2542, 2601, 2701, 2801, 2910, 2911, 3154, 3155, 3210, 3710: Processing Device 212_3, 222_3, 232_3, 242_3, 251_3, 261_3, 271_3, 281_3, 3310: Hidden processing device 1650, 3005: Path controller 2051, 2052, 2140_1, 2140_2, 2140_3, 2240, 2250, 2531, 2532, 2534, 2535: Communication controller 2260: Communication controller master 2270: Communication controller virtual master 2261, 2271: Configuration Controller 2262: Command Controller 2263, 2274: Noise Filter 2143, 2272: Buffer 2273: Serial-Parallel converter 2063, 2350, 2444, 2454, 2559, 2625, 2725, 2825, 2980, 3135, 3162, 3360: Output port 3007, 3031: GPIO (General Purpose Input Output) 2070: Node 1601, 1602, 1605, 3008: Table 2140: GPSB Controller (General Purpose Serial Bus Controller) 2950, ​​3159, 3340, 3420, 3530: Clock generator 3160: Timer 2145, 2533, 2536: Loopback diagnostic device 2160, 2280, 2537, 2900, 3151, 3300, 3451, 3561: GPIO multiplexer 2323, 2331, 2544, 2556: Monitoring device 561, 3733: Communication module 2960, 3161, 3350: Communication Controller UC, UC1, UC1, UC3, UC4, 3860, 3861: User manipulation unit 3910, 3920, 3930, 3940, 3950: Reference table 3450, 3560: Channel Port Mapper 3901, 3910: Event generation device ID 3902, : In-Vehicle device ID 3903: Network apparatus ID associated with the event generating device 3904: Communication protocols for network apparatus 3905: Actuator ID associated with the in-vehicle device 3906: ID of the driving signal processing Unit associated with the actuator 3907: Communication protocol of the drivign signal processing unit 3910: Event Reference Table 3920: Network apparatus reference table 3930: In-vehicle device reference table 3940: Actuator reference table 3950: Driving Signal Processing Unit reference table 3908: Register Information DIS: Diagnostic signal CMD: Command data DPV: Processing result value for Driving DS: Signal for Driving AN: Adjacent node SN: Own node TN: Target node

Claims

Claim 1 A vehicle control device for controlling an actuator within a vehicle, comprising: a first drive control unit and a second drive control unit composed of at least one pair controlling the same actuator; and a clock interface that receives a plurality of independent system clocks having different frequencies and, when an error occurs in the currently selected system clock, automatically switches to the next valid system clock and supplies the clock to the first and second drive control units, wherein the first drive control unit performs a first processing on a first input signal to generate a first actuator driving signal, and the second drive control unit performs a second processing different from the first processing on a second input signal different from the first input signal to generate a second actuator driving signal identical to the first actuator driving signal. Claim 2 A vehicle control device according to claim 1, wherein the first input signal is command data representing a target operation and target state of an actuator, and the second input signal is a driving operation result value including control parameters of a driving signal for achieving the target operation and target state. Claim 3 A vehicle control device according to claim 1, wherein the first processing includes a process of calculating a driving operation result value from the command data, and the second processing includes a process of storing the received driving operation result value in a register, and a driving signal generation module generating a driving signal using the driving operation result value stored in the register and a clock signal. Claim 4 A vehicle control device according to claim 1, wherein the vehicle control device receives the command signal through a plurality of control paths determined according to the location and type of the control unit where the command signal for the target actuator is first received, and applies a 2oo3 (2 out of 3) voting logic to the received plurality of command signals to select a command signal that matches more than a majority. Claim 5 A vehicle control device according to claim 1, characterized in that the first core of the first drive control unit and the second core of the second drive control unit are configured with different performance characteristics. Claim 6 The vehicle control device according to claim 1 further comprises a calculation device that selects a value matching more than half as the final driving calculation result value by applying a predetermined voting logic to a plurality of driving calculation result values, including a first driving calculation result value received from an adjacent control unit and a second driving calculation result value calculated independently for command data identical to the first driving calculation result value. Claim 7 A vehicle control device according to claim 6, wherein the above-described computing device transmits an alarm signal to a central control unit or determines the final driving computation result value in a predetermined safe state when there is no value matching more than a majority when applying the voting logic. Claim 8 A vehicle control device according to claim 1, wherein the first and second drive control units share an output unit, and the output unit includes a hardware comparator that compares whether the first and second actuator driving signals are identical. Claim 9 A vehicle control device according to claim 1, wherein the vehicle control device receives an alarm signal transmitted by an adjacent control unit and identifies an error on the signal path. Claim 10 A vehicle control device according to claim 1, characterized in that when a clock switch occurs in the clock interface, a new clock distribution value corresponding to the changed clock frequency is transmitted to a register to reset the clock generator. Claim 11 A vehicle control device according to claim 4, wherein the vehicle control device monitors the reliability level of each control path, and the reliability level is determined according to the signal delay time, signal congestion, and transmission bandwidth. Claim 12 A vehicle control device according to claim 1, characterized in that when the state of the actuator deviates from a preset state range, the vehicle control device controls the actuator using a safety driving operation result value stored in a safety register. Claim 13 A vehicle control device according to claim 1, characterized in that the first drive control unit and the second drive control unit further include a monitoring device that monitors each other's operation. Claim 14 A vehicle control device according to claim 1, wherein the vehicle control device is mounted in an electronic control unit (ECU) or a zone control unit, and the first and second drive control units are provided inside the electronic control unit (ECU) or the zone control unit. Claim 15 A vehicle control device according to claim 1, wherein the clock interface includes a monitor that detects frequency fluctuations or signal interruptions of the clock to determine errors in the system clock. Claim 16 A vehicle control device according to claim 1, wherein the first drive control unit and the second drive control unit are located in separate zones of the vehicle or within an electronic control unit (ECU) and communicate with each other through a Time Sensitive Networking (TSN) based Ethernet backbone.

Images