WO2022172698A1 - 情報処理装置、移動体装置、および通信システム - Google Patents

情報処理装置、移動体装置、および通信システム Download PDF

Info

Publication number
WO2022172698A1
WO2022172698A1 PCT/JP2022/001450 JP2022001450W WO2022172698A1 WO 2022172698 A1 WO2022172698 A1 WO 2022172698A1 JP 2022001450 W JP2022001450 W JP 2022001450W WO 2022172698 A1 WO2022172698 A1 WO 2022172698A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
communication
phy
cci
extended
Prior art date
Application number
PCT/JP2022/001450
Other languages
English (en)
French (fr)
Inventor
宗 宮本
弘毅 山本
徹 秋下
宏雄 高橋
Original Assignee
ソニーセミコンダクタソリューションズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソニーセミコンダクタソリューションズ株式会社 filed Critical ソニーセミコンダクタソリューションズ株式会社
Priority to JP2022581276A priority Critical patent/JPWO2022172698A1/ja
Priority to US18/037,245 priority patent/US20240007295A1/en
Priority to CN202280013138.8A priority patent/CN116803050A/zh
Publication of WO2022172698A1 publication Critical patent/WO2022172698A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC

Definitions

  • the present disclosure relates to information processing devices, mobile devices, and communication systems, and more particularly to information processing devices, mobile devices, and communication systems that allow the use of session keys.
  • CSI Code Serial Interface-2 ver4.0
  • C-PHY Physical layer
  • D-PHY Physical layer
  • the CSI-2 standard has come to be widely used not only for mobile devices, but also for various purposes such as in-vehicle and IoT (Internet of Things).
  • IoT Internet of Things
  • MIPI Mobile Industry Processor Interface
  • Non-Patent Document 1 a method for establishing an SPDM session is disclosed. Also, in the SPDM extension standard described in Non-Patent Document 2, a method of applying an SPDM session is disclosed.
  • the present disclosure has been made in view of such circumstances, and is intended to solve the problems or problems of information processing devices, mobile devices, and communication systems that use session keys.
  • An information processing apparatus includes a protector that protects first communication between a first device and a second device and second communication between a third device and a second device. ing.
  • the protection unit executes the following (1) to (4). (1) deriving or receiving a first session key; (2) using the first session key for encryption or decryption and message authentication of a first communication; (3) a first session key protected by the first session key; (4) using the second session key for encryption, decryption or message authentication of the second communication, wherein from the start to the end of use of the second session key; The total number of times of communication or the total amount of communication data between is different between the third communication between the first device and the third device and the first communication.
  • a mobile device comprises a protector that protects a first communication between a first device and a second device and a second communication between a third device and a second device. ing.
  • the protection unit executes the following (1) to (4). (1) deriving or receiving a first session key; (2) using the first session key for encryption or decryption and message authentication of a first communication; (3) a first session key protected by the first session key; (4) using the second session key for encryption, decryption or message authentication of the second communication, wherein from the start to the end of use of the second session key; The total number of times of communication or the total amount of communication data between is different between the third communication between the first device and the third device and the first communication.
  • a communication system includes a protector that protects first communication between a first device and a second device and second communication between a third device and a second device.
  • the protection unit executes the following (1) to (4). (1) deriving or receiving a first session key; (2) using the first session key for encryption or decryption and message authentication of a first communication; (3) a first session key protected by the first session key; (4) using the second session key for encryption, decryption or message authentication of the second communication, wherein from the start to the end of use of the second session key; The total number of times of communication or the total amount of communication data between is different between the third communication between the first device and the third device and the first communication.
  • FIG. 1 is a block diagram showing a configuration example of a first embodiment of a communication system to which the present technology is applied;
  • FIG. FIG. 11 is a block diagram showing a configuration example of a second embodiment of a communication system to which the present technology is applied;
  • FIG. 4 is a diagram showing a first structure example of an overall packet structure of an extension packet for D-PHY;
  • FIG. 10 is a diagram showing a first structural example of a packet structure of an extended short packet for D-PHY;
  • FIG. 4 is a diagram showing a first structural example of a packet structure of an extended long packet for D-PHY;
  • FIG. 4 is a diagram showing a first structural example of an overall packet structure of an extension packet for C-PHY;
  • FIG. 4 is a diagram showing a first structural example of a packet structure of an extended short packet for C-PHY;
  • FIG. 4 is a diagram showing a first structural example of a packet structure of an extended long packet for C-PHY; It is a block diagram which shows the structural example of an image sensor.
  • 3 is a block diagram showing a configuration example of an application processor;
  • FIG. 10 is a flowchart for explaining processing in which an image sensor transmits packets; 9 is a flowchart for explaining extended mode transmission processing;
  • FIG. 10 is a flowchart for explaining processing for an application processor to receive a packet;
  • FIG. 9 is a flowchart for explaining extended mode reception processing;
  • FIG. 10 is a diagram illustrating a second structural example of an overall packet structure of an extension packet for D-PHY;
  • FIG. 10 is a diagram illustrating a second structural example of a packet structure of an extended long packet for D-PHY;
  • FIG. 10 is a diagram showing a second structural example of a packet structure of an extended short packet for C-PHY;
  • FIG. 10 is a diagram illustrating a second structural example of a packet structure of an extended long packet for C-PHY;
  • FIG. 11 is a block diagram showing a modification of the configuration for switching between D-PHY and C-PHY;
  • FIG. 11 is a block diagram showing a configuration example of a third embodiment of a communication system to which the present technology is applied;
  • FIG. 10 is a diagram showing a structure example of an extension packet for D-PHY that complies with the regulation of packet alteration prohibition;
  • FIG. 10 is a diagram showing an example structure of an extension packet for C-PHY that conforms to the regulation of packet alteration prohibition;
  • FIG. 10 is a diagram showing an example of the structure of an extension packet for A-PHY that complies with the regulation of packet alteration prohibition;
  • FIG. 10 is a flowchart for explaining packet transmission/reception processing that conforms to the regulation of packet alteration prohibition;
  • FIG. FIG. 3 is a block diagram showing a configuration example of an image sensor that conforms to the regulation prohibiting packet alteration;
  • FIG. 3 is a diagram showing an example of a packet configuration of a read command generated on the application processor side;
  • FIG. 4 is a diagram showing an example of a packet configuration of a read command transferred by A-PHY;
  • FIG. 4 is a diagram showing an example of a packet configuration of a read command and read data on the image sensor side;
  • FIG. 4 is a diagram showing an example of a packet configuration of read data transferred by A-PHY;
  • FIG. 4 is a diagram showing an example of a packet configuration of read data acquired by an application processor;
  • FIG. 4 is a diagram illustrating an example of a packet configuration of write data generated on the application processor side;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data transferred by A-PHY;
  • FIG. 3 is a diagram showing an example of a packet configuration of write data acquired by an image sensor;
  • FIG. 4 is a diagram illustrating an outline of an extended packet header ePH and an extended packet footer ePF;
  • FIG. 10 is a flowchart for explaining initial setting and confirmation operation of communication processing using CCI-FS;
  • FIG. 4 is a flow chart for explaining a write operation using CCI-FS; 4 is a flow chart explaining a read operation using CCI-FS; 1 is a block diagram showing a configuration example of a communication system in which an image sensor and an application processor are configured for SerDes connection;
  • FIG. 3 is a diagram showing an example of a packet configuration of a read command generated on the application processor side;
  • FIG. 4 is a diagram showing an example of a packet configuration of a read command output by I2C/I3C;
  • FIG. 4 is a diagram showing an example of a packet configuration of a read command transferred by A-PHY;
  • FIG. 3 is a diagram showing an example of a packet configuration of read data generated by a SerDes device on the slave side;
  • FIG. 4 is a diagram showing an example of a packet configuration of a read command and read data on the image sensor side;
  • FIG. 4 is a diagram showing an example of a packet configuration of read data output by I2C/I3C;
  • FIG. 4 is a diagram showing an example of a packet configuration of read data transferred by A-PHY;
  • FIG. 4 is a diagram showing an example of a packet configuration of read data output by I2C/I3C;
  • FIG. 4 is a diagram showing an example of a packet configuration of read data acquired by an application processor;
  • FIG. 10 is a flowchart for explaining initial setting and confirmation operation of communication processing using CCI-FS;
  • FIG. 4 is a flow chart for explaining a write operation using CCI-FS; 4 is a flow chart explaining a read operation using CCI-FS; FIG. 10 is a flowchart for explaining Sequence A_Write (during AP) processing; FIG. FIG. 10 is a flowchart for explaining Sequence A_Read_CMD (during AP) processing; FIG. FIG. 10 is a flowchart for explaining Sequence C (during AP) processing; FIG. FIG. 10 is a flowchart for explaining Sequence B (SerDes (Slave)) processing; FIG. FIG. 10 is a flowchart for explaining Sequence A_Read_Data (during AP) processing; FIG. FIG.
  • FIG. 4 is a diagram showing details of an extended packet header ePH0, an extended packet header ePH1, and an extended packet header ePH2;
  • FIG. 10 is a diagram showing details of an extended packet header ePH3;
  • FIG. 10 is a diagram showing details of the extended DT of the extended packet header ePH;
  • FIG. 11 is a block diagram showing a configuration example of conventional I2C hardware;
  • FIG. 4 is a diagram showing an example of waveforms during data transfer on the I2C bus;
  • FIG. 4 is a block diagram showing an example of a circuit configuration of a CCI-FS processing unit;
  • FIG. 4 is a diagram showing a register configuration example;
  • FIG. 10 is a diagram showing an example of a register configuration when configuring a bridge;
  • FIG. 10 is a diagram showing a register configuration example of an error-related register;
  • FIG. 10 is a diagram showing a modified example of the extension packet header ePH in the packet configuration of write data generated on the application processor side;
  • FIG. 10 is a diagram showing a modified example of an extended packet header ePH in the packet configuration of a read command generated on the application processor side;
  • FIG. 4 is a diagram illustrating a flow between an application processor and an image sensor in an A-PHY direct connection configuration;
  • FIG. 10 is a diagram illustrating a flow using the Clock Stretch method
  • 2 is a block diagram showing a detailed configuration example of an image sensor including a CCI-FS processing unit
  • FIG. 4 is a block diagram showing a detailed configuration example of an application processor including a CCI-FS processing unit
  • FIG. 12 is a block diagram showing a configuration example of a fourth embodiment of a communication system to which the present technology is applied
  • 3 is a block diagram showing a detailed configuration example of an image sensor
  • FIG. 3 is a block diagram showing a detailed configuration example of an application processor;
  • FIG. 11 is a flowchart for explaining integrity computation value transmission processing;
  • FIG. FIG. 10 is a diagram showing a first modified example of the data structure of image data;
  • FIG. 10 is a diagram showing a second modified example of the data structure of image data;
  • FIG. 10 is a diagram showing a third modified example of the data structure of image data;
  • FIG. 11 is a flow chart for explaining a first processing example of integrity computation value processing;
  • FIG. 11 is a flowchart for explaining a second processing example of integrity computation value processing;
  • FIG. FIG. 13 is a flowchart for explaining a third processing example of integrity computation value processing;
  • FIG. FIG. 14 is a flowchart for explaining a fourth processing example of integrity computation value processing;
  • FIG. FIG. 10 is a diagram showing a first modified example of the data structure of image data
  • FIG. 10 is a diagram showing a second modified example of the data structure of image data
  • FIG. 10 is a diagram showing a third modified example of the data structure of image
  • FIG. 10 is a diagram showing an example of an initial counter block in which an initialization vector is stored;
  • FIG. FIG. 4 is a diagram showing a GHASH function;
  • FIG. 4 is a diagram showing a GCTR function;
  • FIG. 4 is a diagram showing a GCM-AE function;
  • FIG. 4 is a diagram showing a GCM-AD function;
  • FIG. 4 is a diagram showing an example of the data structure of image data for transmitting an integrity calculation value MAC for each line;
  • FIG. 10 is a diagram showing an example of an initialization vector;
  • FIG. FIG. 4 is a diagram showing an example of transmitting an initialization vector from a transmitting side to a receiving side;
  • FIG. 2 is a diagram showing an example of an extended format of CSI-2 or CCI; 10 is a flowchart for explaining transmission processing of the line MAC method; FIG. 4 is a diagram showing an example of the data structure of image data in which an integrity calculation value MAC is arranged for each frame; FIG. 10 is a diagram showing an example of an initialization vector; FIG. FIG. 4 is a diagram showing an example of transmitting an initialization vector from a transmitting side to a receiving side; FIG. 10 is a flowchart for explaining transmission processing of the frame MAC method; FIG. 9 is a flowchart for explaining selection processing; FIG. 4 is a diagram showing an example of security MAC information; FIG. 10 is a diagram showing an example of rollover cycles of message count values and frame count values; FIG.
  • FIG. 4 is a diagram for explaining the configuration of an initialization vector;
  • FIG. 4 is a flowchart for explaining data verification processing; It is a figure explaining a reflection process.
  • FIG. 2 is a diagram showing an example of a security protocol;
  • FIG. 10 is a diagram showing an example of Source ID or Final Destination ID;
  • FIG. 3 is a block diagram showing a detailed configuration example of an image sensor that diagnoses the presence or absence of an abnormality in itself;
  • 10 is a flowchart for explaining interference detection processing (part 1) by an interference detection unit;
  • FIG. 4 is a diagram illustrating a storage method for storing a light emission pattern (light reception pattern) as a storage pattern when realizing a ToF distance measuring sensor using an image sensor;
  • FIG. 4 is a diagram illustrating a storage method for storing a light emission pattern (light reception pattern) as a storage pattern when realizing a ToF distance measuring sensor using an image sensor;
  • FIG. 4 is a diagram illustrating a storage method for storing a light emission pattern (light reception pattern) as a storage pattern when realizing a ToF distance measuring sensor using an image sensor;
  • FIG. 10 is a flowchart for explaining a disturbance detection process (part 2) by a disturbance detection unit;
  • FIG. 6 is a flowchart for explaining failure detection processing by a failure detection unit;
  • 10 is a flowchart for explaining abnormality detection processing of a security unit by an infringement detection unit;
  • 4 is a flowchart for explaining abnormality detection processing by a temperature detection unit;
  • FIG. 10 is a flowchart for explaining a disturbance detection process (part 2) by a disturbance detection unit;
  • FIG. 6 is a flowchart for explaining failure detection processing by a failure detection unit;
  • 10 is a flowchart for explaining abnormality detection processing of a security unit by an infringement detection unit;
  • 4 is a flowchart for explaining abnormality detection processing by a temperature detection unit;
  • FIG. 3 is a block diagram showing a detailed configuration example of an application processor that detects the presence or absence of an abnormality in an image sensor; 4 is a flowchart for explaining processing of the image sensor when an application processor performs processing for detecting the presence or absence of an abnormality in the image sensor; 5 is a flowchart for explaining processing of the application processor when the application processor performs processing for detecting the presence or absence of an abnormality in the image sensor; FIG. 10 is a diagram showing an example of the data structure of image data for explaining the location of storing a specific message when achieving high-speed data transmission of the specific message without interfering with high-speed data transmission of image data; FIG.
  • FIG. 10 is a flow chart illustrating processing when high-speed data transmission of a specific message is performed without interfering with high-speed data transmission of image data;
  • FIG. 10 is a flowchart for explaining image transmission processing (part 1);
  • FIG. 11 is a flowchart illustrating an application example of image transmission processing (part 1);
  • FIG. FIG. 11 is a flowchart for explaining image transmission processing (part 2);
  • FIG. 10 is a flowchart for explaining image transmission processing (part 3) by an image sensor;
  • FIG. 11 is a flowchart for explaining imaging transmission processing (part 3) by an application processor;
  • FIG. 11 is a flowchart for explaining imaging transmission processing (part 4) by an image sensor;
  • FIG. 11 is a flowchart for explaining image transmission processing (No. 8) by an image sensor; FIG. FIG. 11 is a flowchart for explaining image transmission processing (No. 8) by an application processor; FIG. FIG. 13 is a flowchart for explaining image transmission processing (No. 9); FIG. FIG. 11 is a flowchart for explaining image transmission processing (No. 10); FIG. FIG. 11 is a flowchart for explaining image transmission processing (No. 11); FIG. FIG. 10 is a diagram for explaining message count values using two types of count values with different Hamming distances; FIG. 10 is a diagram illustrating a method of detecting whether or not a message count value is defective or falsified using two types of count values; FIG.
  • FIG. 10 is a diagram illustrating a method of detecting whether or not a message count value is defective or falsified using two types of count values; 10 is a flowchart for explaining message count processing; FIG. 10 is a diagram illustrating a configuration example of an extension packet header ePH2 when a Warning Descriptor is set in a reserved area (Reserved) in the extension packet header ePH2; FIG. 10 is a diagram illustrating a description example of identification information using each bit of Warning Descriptor (specific message); FIG. 10 is a diagram illustrating a configuration example when a warning bulletin (eg, physical attack detection) is set as the first specific message in the extension packet header; FIG.
  • a warning bulletin eg, physical attack detection
  • FIG. 11 is a flow chart for explaining transmission processing of the image sensor when a specific message is separated and transmitted;
  • FIG. 11 is a flow chart for explaining transmission processing of an application processor when a specific message is separated and transmitted;
  • FIG. 10 is a flowchart for explaining transmission processing when a peculiar message is separated and transmitted when a warning detail reading command is transmitted after a warning bulletin is transmitted;
  • FIG. 13 is a diagram illustrating a configuration example of a Security Descriptor in which any specific message is set, such as whether there is an abnormality inside or outside the image sensor 1211, whether there is interference or an attack on the image sensor 1211, or the like.
  • 1 is a block diagram showing a configuration example of a propulsion device in which an image sensor and an application processor are mounted;
  • FIG. 161 is a diagram illustrating a propulsion control process (part 1) for controlling propulsion of the propulsion device of FIG. 160;
  • FIG. 161 is a diagram illustrating a propulsion control process (part 2) for controlling propulsion of the propulsion device of FIG. 160;
  • 161 is a diagram for explaining propulsion control processing (3) by a microcomputer that controls propulsion of the propulsion device of FIG. 160;
  • FIG. FIG. 161 is a diagram for explaining propulsion control processing (part 3) by an imaging unit that controls propulsion of the propulsion device of FIG. 160;
  • FIG. 10 is a diagram illustrating a configuration example of a HEARTBEAT request message;
  • FIG. 10 is a diagram illustrating a configuration example of a HEARTBEAT_ACK response message;
  • FIG. 10 is a diagram illustrating a configuration example of a HEARTBEAT_NAK response message;
  • FIG. 10 is a diagram illustrating a configuration example of an END_SESSION request message;
  • 10 is a flowchart for explaining HEARTBEAT processing (part 1);
  • FIG. 10 is a diagram illustrating a configuration example of an END_SESSION_NAK response message;
  • FIG. 10 is a flowchart for explaining HEARTBEAT processing (part 2) of a CCI host (requester);
  • FIG. 10 is a flowchart for explaining HEARTBEAT processing (part 2) of a CCI device (responder);
  • FIG. 10 is a flowchart for explaining HEARTBEAT processing (part 3) of a CCI host (requester);
  • FIG. 10 is a flowchart for explaining HEARTBEAT processing (part 3) of a CCI device (responder);
  • FIG. 10 is a diagram illustrating a configuration example of an ERROR response message;
  • FIG. 10 is a diagram illustrating an example of setting Error code and Error data;
  • FIG. 10 is a diagram illustrating an example of setting ExtendedErrorData;
  • FIG. 11 is a diagram illustrating a setting example of a Registry or standards body ID when a pseudo-HEARTBEAT function is used;
  • FIG. 10 is a diagram illustrating a setting example of a VENDOR_DEFINED_REQUEST request message;
  • FIG. 10 is a diagram illustrating a setting example of a VENDOR_DEFINED_RESPONSE response message;
  • FIG. 4 is a diagram for explaining an SPDM key schedule;
  • FIG. 10 is a diagram showing an example of KEY_UPDATA_operations;
  • FIG. 11 is a flowchart for explaining an example of the flow of processing related to key update;
  • FIG. FIG. 10 is a diagram showing an example of ePH2;
  • FIG. 10 is a flowchart illustrating an example of the flow of session key update
  • FIG. 4 is a flowchart illustrating an example of a processor processing flow
  • 6 is a flowchart for explaining an example of the flow of sensor processing
  • FIG. 10 is a flowchart illustrating an example of the flow of session key update
  • FIG. 4 is a flowchart illustrating an example of a processor processing flow
  • 6 is a flowchart for explaining an example of the flow of sensor processing
  • 4 is a flowchart illustrating an example of a processor processing flow
  • 6 is a flowchart for explaining an example of the flow of sensor processing
  • 6 is a flowchart for explaining an example of the flow of sensor processing
  • FIG. 10 is a diagram showing an example of KeyUpdataReq and KeySwitchTiming; FIG. 10 is a flowchart illustrating an example of the flow of session key update; FIG. 4 is a flowchart illustrating an example of a processor processing flow; 6 is a flowchart for explaining an example of the flow of sensor processing; 4 is a flowchart illustrating an example of a processor processing flow; 6 is a flowchart for explaining an example of the flow of sensor processing; 4 is a flowchart illustrating an example of a processor processing flow; 6 is a flowchart for explaining an example of the flow of sensor processing; 4 is a flowchart illustrating an example of a processor processing flow; 6 is a flowchart for explaining an example of the flow of sensor processing; FIG.
  • FIG. 10 is a diagram showing an example of EvenOddkey
  • FIG. 4 is a diagram showing an example of derivation of a session key
  • FIG. 4 is a diagram showing an example of derivation of a session key
  • FIG. 12 is a block diagram showing a configuration example of a fifth embodiment of a communication system to which the present technology is applied
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor;
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor;
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor;
  • FIG. 11 is a block diagram showing a modification of the configuration of the image sensor and processor;
  • FIG. 4 is a diagram showing an example of countermeasures against replay attacks in control system communication (Control Plane);
  • FIG. 10 is a diagram showing an example of an initialization vector;
  • FIG. 10 is a diagram showing an example of Write message;
  • FIG. 10 is a diagram showing an example of Write message;
  • FIG. 4 is a diagram showing an example of countermeasures against replay attacks in control system communication (Control Plane);
  • FIG. 10 is a diagram showing an example of an initialization vector;
  • FIG. 10 is a diagram showing an example of Write message;
  • FIG. 10 is a diagram showing an example of Write message;
  • FIG. 10 is a diagram illustrating a setting example of a VENDOR_DEFINED_REQUEST request message;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 10 is a diagram illustrating a setting example of a VENDOR_DEFINED_REQUEST request message;
  • FIG. 3 is a diagram showing an example of a packet configuration of read data;
  • FIG. 10 is a diagram showing an example of countermeasures against replay attacks in image communication (Data Plane);
  • FIG. 10 is a diagram showing an example of countermeasures against replay attacks in image communication (Data Plane);
  • FIG. 3 is a diagram showing an example of the data structure of image data
  • FIG. 10 is a diagram showing an example of countermeasures against replay attacks in image communication (Data Plane);
  • FIG. 3 is a diagram showing an example of the data structure of image data;
  • FIG. 233 is a diagram explaining the terms of FIG. 232;
  • FIG. 11 is a flowchart illustrating an example of session key generation and transmission processing in SSMC;
  • FIG. 235 is a flowchart illustrating an example of processing subsequent to FIG. 234;
  • FIG. FIG. 13 is a flowchart illustrating an example of session key update processing at one end of the SoC or Bridge;
  • FIG. 10 is a flowchart illustrating an example of session key update processing at the other end of a sensor or bridge;
  • FIG. 11 is a flowchart illustrating an example of session key generation and transmission processing in SSMC;
  • FIG. FIG. 239 is a flowchart illustrating an example of processing subsequent to FIG. 238;
  • FIG. FIG. 10 is a flowchart illustrating an example of session key update processing at one end of the SoC or Bridge;
  • FIG. 10 is a flowchart illustrating an example of session key update processing at the other end of a sensor or bridge;
  • FIG. 209 is a block diagram showing a modified example of the configuration of FIG. 208;
  • FIG. FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 10 is a diagram illustrating an example of write data processing;
  • FIG. 4 is a diagram showing an example of a function register;
  • FIG. 4 is a diagram showing an example of a function register; FIG. FIG. 4 is a diagram showing an example of a packet configuration of read data; FIG. 10 is a diagram illustrating an example of read data processing; FIG. 4 is a diagram showing an example of a packet configuration of write data; FIG. 10 is a diagram illustrating an example of write data processing; FIG. 10 is a diagram showing an example of setting EXTENDED HEADER; FIG. 4 is a diagram showing an example of a packet configuration of write data; FIG. 10 is a diagram showing an example of setting EXTENDED HEADER; FIG. 4 is a diagram showing an example of a packet configuration of write data; FIG.
  • FIG. 10 is a diagram illustrating an example of write data processing; 9 is a flowchart illustrating an example of MAC or CRC arithmetic processing in the second CCI mode; FIG. 10 is a diagram showing a setting example of Register definition and EXTENDED HEADER; FIG. 4 is a diagram showing an example of a packet configuration of write data; FIG. 10 is a diagram illustrating an example of write data processing; 9 is a flowchart illustrating an example of GCM or CCM arithmetic processing in the second CCI mode; FIG. 10 is a diagram showing a setting example of Register definition and EXTENDED HEADER; FIG. 4 is a diagram showing an example of a packet configuration of write data; FIG.
  • FIG. 10 is a diagram illustrating an example of write data processing;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 10 is a diagram illustrating an example of write data processing;
  • 7 is a flowchart illustrating an example of GCM or CCM arithmetic processing in the first CCI mode;
  • FIG. 10 is a diagram showing a setting example of a Capability register;
  • FIG. 10 is a diagram showing a setting example of Vendor defined SPDM message;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 10 is a diagram illustrating an example of write data processing;
  • 7 is a flowchart for explaining an example of switching of an internal processing order;
  • FIG. 10 is a diagram showing a setting example of a Capability register;
  • FIG. 10 is a diagram showing a setting example of Vendor defined SPDM message;
  • 7 is a flowchart for explaining an example of switching of an internal processing order;
  • 7 is a flowchart for explaining an example of switching of an internal processing order;
  • FIG. 11 is a flowchart illustrating an example of initialization vector notification processing;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 4 is a diagram showing an example of a packet configuration of write data;
  • FIG. 10 is a diagram showing a setting example of a Capability register;
  • FIG. 10 is a diagram showing a setting example of Vendor defined SPDM message;
  • FIG. 10 is a diagram showing an example of setting EXTENDED HEADER;
  • 10 is a flow chart illustrating an example of a message authentication procedure;
  • FIG. 4 is a diagram showing an example of a message authentication policy;
  • FIG. 4 is a diagram showing an example of a message authentication policy;
  • FIG. 4 is a diagram showing an example of a message authentication policy;
  • FIG. 10 is a diagram showing an example of a message authentication policy;
  • FIG. 10 is a diagram showing a setting example of a Capability register;
  • FIG. 10 is a diagram showing a setting example of Vendor defined SPDM message;
  • FIG. 10 is a diagram showing an example of an initialization vector;
  • FIG. 10 is a diagram showing an example of an initialization vector;
  • FIG. FIG. 10 is a diagram showing an example
  • FIG. 1 is a block diagram showing a configuration example of a first embodiment of a communication system to which the present technology is applied.
  • the communication system 11 is configured by connecting an image sensor 21 and an application processor 22 via a bus 23 .
  • the communication system 11 is used for CSI-2 connections inside existing mobile devices such as so-called smart phones.
  • the image sensor 21 is configured by incorporating, for example, a CSI-2 transmission circuit 31 compatible with the extension mode together with a lens and an imaging device (none of which are shown). For example, the image sensor 21 transmits image data of an image captured by the imaging element to the application processor 22 by means of the extension mode compatible CSI-2 transmission circuit 31 .
  • the application processor 22 is configured with an LSI (Large Scale Integration) and a CSI-2 receiver circuit 32 compatible with extended mode. This LSI performs processing according to various applications executed by the mobile device provided with the communication system 11 .
  • the application processor 22 receives, for example, image data transmitted from the image sensor 21 by means of the extension mode compatible CSI-2 receiving circuit 32 .
  • the application processor 22, for example, uses an LSI to process the image data in accordance with the application.
  • the bus 23 is a communication path that transmits signals in compliance with the CSI-2 standard. In the bus 23, for example, the transmission distance over which signals can be transmitted is about 30 cm. Also, the bus 23 connects the image sensor 21 and the application processor 22 by a plurality of signal lines (I2C, CLKP/N, D0P/N, D1P/N, D2P/N, D3P/N) as shown. .
  • the extended mode compatible CSI-2 transmitting circuit 31 and the extended mode compatible CSI-2 receiving circuit 32 are compatible with communication in the extended mode, which is an extension of the CSI-2 standard, and transmit and receive signals with each other. can be done.
  • the detailed configuration of the extended mode compatible CSI-2 transmitting circuit 31 and the extended mode compatible CSI-2 receiving circuit 32 will be described later with reference to FIGS.
  • FIG. 2 is a block diagram showing a configuration example of a second embodiment of a communication system to which the present technology is applied.
  • the image sensor 21 and the SerDes device 25 are connected via a bus 24-1.
  • application processor 22 and SerDes device 26 are connected via bus 24-2.
  • a SerDes device 25 and a SerDes device 26 are connected via a bus 27 in the communication system 11A.
  • the communication system 11A is used for connection in existing vehicle-mounted cameras.
  • the image sensor 21 and the application processor 22 are configured in the same manner as the image sensor 21 and the application processor 22 in FIG. 1, and detailed description thereof will be omitted.
  • the buses 24-1 and 24-2, like the bus 23 in FIG. 1, are communication paths for transmitting signals in compliance with the CSI-2 standard. , I2C/I3C, CLKP/N, D0P/N, D1P/N, D2P/N, D3P/N).
  • the SerDes device 25 is configured with a CSI-2 receiving circuit 33 and a SerDes (Serializer/Deserializer) transmitting circuit 34 .
  • the SerDes device 25 is transmitted from the image sensor 21 by the CSI-2 receiving circuit 33 communicating with the extended mode compatible CSI-2 transmitting circuit 31 in accordance with the normal CSI-2 standard. Get the incoming bit-parallel signal. Then, the SerDes device 25 converts the acquired signal into bit serial, and the SerDes transmission circuit 34 communicates with the SerDes reception circuit 35 on one lane, thereby transmitting the signal to the SerDes device 26. do.
  • the SerDes device 26 is configured with a SerDes receiving circuit 35 and a CSI-2 transmitting circuit 36.
  • the SerDes device 26 acquires a serial bit signal transmitted by the SerDes receiving circuit 35 communicating with the SerDes transmitting circuit 34 through one lane. Then, the SerDes device 26 converts the acquired signal into bit-parallel, and the CSI-2 transmission circuit 36 complies with the normal CSI-2 standard between the extension mode compatible CSI-2 reception circuit 32 and the CSI-2 transmission circuit 36. It transmits to the application processor 22 by communicating.
  • the bus 27 is a communication path that transmits signals in compliance with standards such as A-PHY and FPD (Flat Panel Display)-LINK III.
  • the transmission distance over which signals can be transmitted is a long distance of about 15 m.
  • MIPI A-PHY has an asymmetric data link layer (asymmetric upper layer) with a point-to-point topology, allowing high-speed data transmission, control data, and power to share the same physical wiring. MIPI A-PHY serves as the foundation for end-to-end systems designed to simplify the integration of cameras, sensors, and displays, while also allowing functional safety and security to be incorporated.
  • the communication systems 11 and 11A configured in this way transmit and receive data in packets having an extended packet structure as described later by means of an extended mode compatible CSI-2 transmission circuit 31 and an extended mode compatible CSI-2 receiving circuit 32. be able to.
  • This makes it possible to support a wider variety of uses, such as RAW24, SmartROI (Region of Interest), and GLD (Graceful Link Degradation), which will be described later.
  • FIG. 3 shows the overall packet structure of a packet used in the CSI-2 extension mode when the physical layer is D-PHY (hereinafter referred to as D-PHY extension packet).
  • the extended packet for D-PHY has the same packet structure as the existing CSI-2 standard in the packet header and packet footer.
  • the packet header stores VC (VirtualChannel) indicating the number of virtual channels, data type (DataType) indicating the type of data, WC (Word Count) indicating the data length of the payload, and VCX/ECC.
  • the packet footer stores a CRC (Cyclic Redundancy Check).
  • 0x38 to x3F are defined as reserved for data types transmitted in packet headers. Therefore, in the extension packet for D-PHY, setting information for identifying the extension mode on the receiving side is newly defined by using the existing reserved data type.
  • DataType[5:3] is defined as extended mode setting information
  • DataType[1:0] is the extended type. Defined as configuration information.
  • the extended mode setting information indicates whether or not the extended mode is set. For example, when DataType[5:3] is 3'b111, it indicates the extended mode. Also, when four types of extension mode 0, extension mode 1, extension mode 2, and extension mode 3 are prepared as types of extension mode, the extension type setting information is any type among them. or For example, when DataType[1:0] is 2'b00, it indicates that the extension mode type is extension mode 0.
  • a packet structure is defined in which the payload is separated into four. That is, the payload in extended mode 0 is, as shown in FIG. 3, an extended packet header (ePH), an optional extended packet header (OePH), a legacy payload (Legacy Payload), and an optional Separated into the Optional extended Packet Footer (OePF). Note that the extended packet header may be repeatedly transmitted.
  • the extended packet header is placed at the beginning of the existing CSI-2 standard payload, and must always be sent in extended mode.
  • the extended packet header is composed of setting information such as an SROI identification flag, extended VC (Virtual Channel), extended DataType, OePH selection flag, and OePF selection flag.
  • the extended VC extends the VC, which was 4 bits in the existing CSI-2 standard, to 8 bits
  • the extended DataType extends the DataType, which was 4 bits in the existing CSI-2 standard, to 8 bits. be.
  • the VC of the existing packet header already exists with 4 bits, and by defining the extended VC of the extended packet header as 4 bits, the total can be 8 bits.
  • OePH[7:0] ⁇ 5'h00,RSID,XY_POS,MC ⁇
  • OePF[3:0] ⁇ 3'h0,pCRC ⁇
  • ON/OFF of packet transmission can be controlled.
  • the optional extension packet header and optional extension packet footer are selectively transmitted according to the application.
  • the legacy payload corresponds to the same payload as the existing CSI-2 standard.
  • the extended packet header, optional extended packet header, and optional extended packet footer As needed, it is possible to transmit data for various purposes.
  • the data transmitted by the extended packet header, optional extended packet header, and optional extended packet footer shall be 26bit+6bit ECC (Error Correction Code).
  • ECC Error Correction Code
  • FIG. 4 shows a short packet (hereinafter referred to as D-PHY (referred to as an extended short packet for .NET) is shown.
  • FIG. 5 shows the packet structure of a long packet (hereinafter referred to as an extended long packet for D-PHY) used in the extended mode of CSI-2 when the physical layer is D-PHY.
  • This Short Packet Data Field is identical to that defined in the existing CSI-2 standard.
  • MC MessageCount for GLD
  • RSID vehicle line number and SourceID
  • the extended short packet with the packet structure as shown in FIG. 4 can extend the data type and the bit width of the virtual channel compared to the extended short packet according to the existing CSI-2 standard.
  • Various uses defined in the extended packet header can be supported. Also, if these functions are not required, an extended short packet conforming to the existing CSI-2 standard may be transmitted together with an extended long packet.
  • the optional extended packet header, legacy payload, and optional extended packet footer are stored in the existing CSI-2 standard payload and transmitted.
  • the existing SerDes transmission circuit 34 and SerDes reception circuit 35 (FIG. 2) recognize it in the same way as the image data transmitted with the existing payload, and the image data is transmitted as it is. It is transmitted to the later stage.
  • the last-stage application processor 22 can determine the extension mode from the data type DT[5:0] of the packet header. Therefore, the application processor 22 can interpret the contents of the payload in order from the extension packet header and extract the desired extension mode data.
  • FIG. 6 shows the overall packet structure of a packet used in the CSI-2 extension mode when the physical layer is C-PHY (hereinafter referred to as an extension packet for C-PHY).
  • an extension packet for C-PHY shown in FIG. 6, the description of the configuration common to the extension packet for D-PHY in FIG. 3 is omitted, and the configuration different is described.
  • extension packet for C-PHY similar to the extension packet for D-PHY in FIG. It is embedded in the payload and transmitted.
  • the extended packet for C-PHY transmits the packet header twice in the same way as the packet for C-PHY conforming to the existing CSI-2 standard, and the C-PHY converts 16 bits into 7 symbols. Arrange the data in 16-bit units for convenience of conversion to .
  • the extension packet header is placed at the beginning of the payload, but with respect to the virtual channel, in the case of C-PHY, the beginning of the existing packet header was reserved for that purpose, so the extension packet header has the virtual channel is not stored.
  • the virtual channel may be stored in the extension packet header.
  • a flag called OePHF is prepared, and if this flag is 1, the OePH/OePF information is transmitted next.
  • a CRC is transmitted as an extended packet header, and similarly configured packet headers are repeatedly transmitted twice. In this way, by making the structure the same as the existing mechanism in which the packet header is transmitted twice, it is possible to achieve both circuit reusability and error tolerance.
  • FIG. 7 shows a short packet (hereinafter referred to as C-PHY (referred to as an extended short packet for .NET) is shown.
  • FIG. 8 shows a packet structure of a long packet (hereinafter referred to as an extended long packet for C-PHY) used in CSI-2 extended mode when the physical layer is C-PHY.
  • the extended short packet for C-PHY shown in FIG. 7 is not significantly different in packet structure from the extended short packet for D-PHY shown in FIG. 4, and the extended long packet for C-PHY shown in FIG. , there is no significant difference in the packet structure from the extended long packet for D-PHY shown in FIG.
  • FIG. 9 is a block diagram showing a configuration example of the image sensor 21 including the extended mode compatible CSI-2 transmission circuit 31. As shown in FIG.
  • the image sensor 21 includes pixels 41, an AD converter 42, an image processing unit 43, a pixel CRC calculation unit 44, a physical layer processing unit 45, a CSI-2 transmission circuit 31 compatible with the extension mode, It comprises an I2C/I3C slave 46 and a register 47 .
  • the extension mode compatible CSI-2 transmission circuit 31 includes a packing unit 51, a packet header generation unit 52, an extension packet header generation unit 53, an extension packet footer generation unit 54, selection units 55 and 56, a CRC calculation unit 57, and lane distribution. It comprises a unit 58 , a CCI slave 59 and a controller 60 .
  • the pixel 41 outputs an analog pixel signal corresponding to the amount of light received, and an AD converter (ADC: Analog-to-Digital Converter) 42 converts the pixel signal output from the pixel 41 into a digital image. It is supplied to the processing section 43 .
  • An image signal processor (ISP) 43 supplies image data obtained by performing various types of image processing on an image based on pixel signals to a pixel CRC calculator 44 and a packing unit 51 .
  • the image processing unit 43 also supplies a data enable signal data_en indicating whether the image data is valid to the packing unit 51 and the controller 60 .
  • the pixel CRC calculation unit 44 calculates and obtains the CRC for each pixel in the image data supplied from the image processing unit 43 and supplies the CRC to the extension packet footer generation unit 54 .
  • the physical layer processing unit 45 can perform both C-PHY and D-PHY physical layer processing. For example, the physical layer processing unit 45 performs physical layer processing of the C-PHY when the C layer enable signal cphy_en supplied from the controller 60 is valid, and when the C layer enable signal cphy_en is invalid. Performs physical layer processing for D-PHY. The physical layer processing unit 45 then transmits the packets divided into four lanes by the lane distribution unit 58 to the application processor 22 .
  • the I2C/I3C slave 46 communicates under the initiative of the I2C/I3C master 72 (FIG. 10) of the application processor 22 based on the I2C (Inter-Integrated Circuit) or I3C (Improved Inter-Integrated Circuits) standard.
  • settings sent from the application processor 22 are written to the register 47 via the I2C/I3C slave 46 and the CCI slave 59.
  • the settings written to the register 47 include, for example, communication settings according to the CSI-2 standard, extended mode settings indicating whether or not extended mode is used, and fixed communication settings required for communication in extended mode. and so on.
  • the packing unit 51 performs packing processing to store the image data supplied from the image processing unit 43 in the payload of the packet, and supplies the payload to the selection unit 55 and the lane distribution unit 58 .
  • the packet header generation unit 52 When the packet header generation unit 52 is instructed to generate a packet header according to the packet header generation instruction signal ph_go supplied from the controller 60 , the packet header generation unit 52 generates a packet header and supplies it to the selection unit 55 and the lane distribution unit 58 .
  • the packet header generation unit 52 generates, according to the existing CSI-2 standard, setting information indicating conditions set for data transmitted in a packet, for example, a packet header storing a data type indicating a data type. .
  • the packet header generation unit 52 uses an extension header in the unused area defined as unused in the existing CSI-2 standard in the data type, which is setting information indicating the type of data transmitted in the packet. It stores extended mode setting information indicating whether or not the extended mode is the extended mode.
  • the packet header generation unit 52 stores extension type setting information indicating which type of extension mode is one of a plurality of types of extension modes prepared as the extension mode in the unused area.
  • the extended packet header generator 53 generates an extended packet header and an optional extended packet header according to an extended packet header generation instruction signal eph_go and an extended packet header enable signal ePH_en supplied from the controller 60, and selects a selector 56 and a lane distributor. 58. Further, the extension packet header generation unit 53 is supplied with a vehicle line number, a source ID (identification), etc. according to the application of the image sensor 21, and if necessary, these are supplied as extension packet headers or optional extension packet headers. stored in
  • the extended packet header generating unit 53 generates, for example, an extended packet header storing setting information as shown in FIG. 3, separately from the packet header generated by the packet header generating unit 52. Further, when transmitting the optional extension packet header, the extension packet header generation unit 53 generates the optional extension packet header setting information (OePH[7:0]) indicating whether or not to transmit the optional extension packet header. Optional extension packet header setting information indicating that the header is to be transmitted is stored in the extension packet header, and an optional extension packet header is generated following the extension packet header.
  • the extended packet footer generator 54 generates an optional extended packet footer according to the extended packet footer generation instruction signal epf_go and the extended packet header enable signal ePF_en supplied from the controller 60 and supplies it to the selector 56 and the lane distributor 58 .
  • the extended packet footer generation unit 54 when the packet transmitted in the extended mode is an extended long packet that stores data transmitted as a payload in the existing CSI-2 standard, the extended packet footer generation unit 54 generates a legacy payload in which data is stored. Generates an optional extension packet footer that follows the .
  • a layer C enable signal cphy_en is supplied from the controller 60 to the packet header generator 52 , the extended packet header generator 53 , and the extended packet footer generator 54 . Then, when the C layer enable signal cphy_en indicates valid, the packet header generation unit 52 generates a packet header for C-PHY, and the extension packet header generation unit 53 generates an extension packet header for C-PHY and optional extensions. A packet header is generated, and an extended packet footer generator 54 generates an optional extended packet footer for C-PHY. On the other hand, when the C-layer enable signal cphy_en indicates invalidity, the packet header generator 52 generates a packet header for D-PHY, and the extended packet header generator 53 generates an extended packet header for D-PHY and optional extensions. A packet header is generated, and an extended packet footer generator 54 generates an optional extended packet footer for D-PHY.
  • the selection unit 55 selects the packet header supplied from the packet header generation unit 52 according to the C layer enable signal cphy_en supplied from the controller 60 when the C layer enable signal cphy_en is valid, and supplies the selected packet header to the selection unit 56 . .
  • the selection unit 55 selects the payload supplied from the packing unit 51 and supplies it to the selection unit 56 .
  • the selection unit 56 selects the packet header or payload selectively supplied via the selection unit 55, the extension packet header supplied from the extension packet header generation unit 53, and the optional extension according to the data selection signal data_sel supplied from the controller 60.
  • One of the packet header and the optional extended packet footer supplied from the extended packet footer generator 54 is selected and supplied to the CRC calculator 57 .
  • the CRC calculation unit 57 calculates and obtains the CRC of the packet header, payload, extended packet header, optional extended packet header, or optional extended packet footer selectively supplied via the selection unit 56, and distributes the CRC to lanes. 58.
  • the lane distribution unit 58 distributes the payload supplied from the packing unit 51, the packet header supplied from the packet header generation unit 52, the extension packet header supplied from the extension packet header generation unit 53, and the optional extension packet.
  • the header, the optional extended packet footer supplied from the extended packet footer generation unit 54, and the CRC supplied from the CRC calculation unit 57 are distributed to four lanes according to the CSI-2 standard, and the physical layer processing unit 45 supply to
  • the CCI (Camera Control Interface) slave 59 communicates under the initiative of the CCI master 88 (Fig. 10) of the application processor 22 based on the CSI-2 standard.
  • the controller 60 reads out various settings stored in the register 47 and controls each block that configures the extended mode compatible CSI-2 transmission circuit 31 according to these settings. For example, the controller 60 controls switching between transmission of packets having a packet structure conforming to the existing CSI-2 standard and transmission of packets having a packet structure in the extended mode according to the content of data to be transmitted.
  • the image sensor 21 is configured in this way, and can generate an extension packet having a packet structure as described with reference to FIGS.
  • FIG. 10 is a block diagram showing a configuration example of the application processor 22 including the extended mode compatible CSI-2 receiver circuit 32. As shown in FIG.
  • the application processor 22 includes a physical layer processing unit 71, an I2C/I3C master 72, a register 73, and a controller 74 in addition to the CSI-2 receiver circuit 32 compatible with the extended mode.
  • the extended mode compatible CSI-2 receiver circuit 32 includes a packet header detector 81, a lane merger 82, an interpreter 83, selectors 84 and 85, a CRC calculator 86, an unpacker 87, and a CCI master 88. configured with.
  • the physical layer processing unit 71 is capable of executing both C-PHY and D-PHY physical layer processing. As described above, the physical layer processing unit 45 of the image sensor 21 performs either one of C-PHY and D-PHY physical layer processing. perform the same physical layer processing as performed in .
  • the I2C/I3C master 72 leads communication with the I2C/I3C slave 46 (FIG. 9) of the image sensor 21 based on the I2C or I3C standard.
  • the controller 74 controls each block that configures the application processor 22 .
  • the packet header detection unit 81 detects the packet header from the packet supplied from the physical layer processing unit 71, and confirms the data type stored in the packet header.
  • the packet header detection unit 81 detects the extended mode detection flag indicating the extended mode. is supplied to the interpreter 83 , the selector 84 and the selector 85 .
  • the packet header detection unit 81 also supplies the lane merging unit 82 with a merge enable signal mrg_en indicating whether to enable merging of the divided four lanes.
  • the packet header detection unit 81 detects packet headers in which setting information (data type, etc.) indicating conditions set for data transmitted in packets is stored according to the existing CSI-2 standard. At this time, the packet header detection unit 81 detects that the data type, which is setting information indicating the type of data transmitted in the packet, is stored in an unused area defined as unused in the existing CSI-2 standard. , by outputting an extension mode detection flag according to the extension mode setting information indicating whether the extension mode is an extension mode using an extension header, reception of a packet with a packet structure conforming to the existing CSI-2 standard and extension mode Allows switching between receiving and receiving packets in a packet structure at the time. Further, the packet header detection unit 81 detects a plurality of types prepared as extended modes according to the extended mode type information stored in the unused area of the data type defined as unused in the existing CSI-2 standard. Recognize which type of extended mode it is.
  • the lane merging unit 82 merges the packets divided into 4 lanes supplied from the physical layer processing unit 71 .
  • the lane merging unit 82 then supplies the packet of one lane to the interpreting unit 83 , the selecting unit 84 , and the selecting unit 85 .
  • the interpreter 83 extracts from the packet supplied from the lane merging unit 82 based on the extended mode packet structure. , Extended Packet Header, Optional Extended Packet Header, and Optional Extended Packet Footer. The interpretation unit 83 then interprets the setting information stored in the extension packet header, optional extension packet header, and optional extension packet footer.
  • the interpreting unit 83 receives, as an extension header, an extension packet header arranged at the beginning of the payload according to the existing CSI-2 standard, and interprets the setting information stored in the extension packet header. Further, if the optional extension packet header setting information stored in the extension packet header indicates that an optional extension packet header that is selectively transmitted according to the application is to be transmitted, the interpretation unit 83 receive the optional extension packet header, and interpret the setting information stored in the optional extension packet header. Furthermore, if the packet transmitted in the extended mode is an extended long packet that stores data transmitted as a payload in the existing CSI-2 standard, the interpreter 83 follows the legacy payload in which the data is stored. Receive an optional extension packet footer to be placed and interpret the optional extension packet footer.
  • the interpreting unit 83 reads, for example, the in-vehicle line number and source ID stored in the optional extension packet header, and outputs them to the subsequent LSI (not shown).
  • the interpreter 83 stops without performing the processing described above.
  • the selection unit 84 selectively supplies data to the unpacking unit 87 according to the extension mode detection flag supplied from the packet header detection unit 81 and based on the packet structure of the existing packet or the packet structure of the extension packet.
  • the selection unit 85 selectively supplies data to the CRC calculation unit 86 according to the extension mode detection flag supplied from the packet header detection unit 81 and based on the packet structure of the existing packet or the packet structure of the extension packet.
  • the CRC calculator 86 calculates the CRC of the packet header, payload, extended packet header, optional extended packet header, or optional extended packet footer selectively supplied via the selector 85 . Then, when a CRC error is detected, the CRC calculator 86 outputs a crcCRC error detection signal indicating the fact to the subsequent LSI (not shown).
  • the unpacking unit 87 performs unpacking processing to extract the image data stored in the payload selectively supplied via the selection unit 84, and outputs the acquired image data to the subsequent LSI (not shown). .
  • the CCI master 88 leads communication with the CCI slave 59 (Fig. 9) of the image sensor 21 based on the CSI-2 standard.
  • the application processor 22 is configured as described above, receives the extension packet transmitted from the image sensor 21, and interprets the setting information stored in the extension packet header, the optional extension packet header, and the optional extension packet footer. to obtain the image data.
  • FIG. 11 is a flowchart for explaining the process of transmitting packets by the image sensor 21.
  • step S ⁇ b>11 the controller 60 determines whether or not to use the extension mode when starting communication with the application processor 22 . For example, controller 60 checks the extended mode setting stored in register 47 and determines to use extended mode if application processor 22 has written an extended mode setting indicating that extended mode is to be used.
  • step S11 if the controller 60 determines not to use the extended mode, the process proceeds to step S12.
  • the I2C/I3C slave 46 receives an image data transmission start command transmitted from the application processor 22 (at step S54 in FIG. 13, which will be described later). Furthermore, the I2C/I3C slave 46 receives the communication setting according to the CSI-2 standard transmitted together with the transmission start instruction, and writes it to the register 47 via the CCI slave 59 .
  • step S13 the image sensor 21 executes conventional packet transmission processing for transmitting a packet having a packet structure conforming to the existing CSI-2 standard to the application processor 22 based on the communication settings stored in the register 47. be done.
  • step S11 determines in step S11 to use the extension mode
  • the process proceeds to step S14.
  • step S14 the I2C/I3C slave 46 receives fixed communication settings required for communication in extended mode (for example, a copy of PH/PF for each lane during GLD), and via the CCI slave 59, write to register 47.
  • fixed communication settings required for communication in extended mode for example, a copy of PH/PF for each lane during GLD
  • the I2C/I3C slave 46 receives an image data transmission start command transmitted from the application processor 22 (at step S57 in FIG. 13, which will be described later). Furthermore, the I2C/I3C slave 46 receives the communication setting according to the CSI-2 standard transmitted together with the transmission start instruction, and writes it to the register 47 via the CCI slave 59 .
  • step S16 the controller 60 determines whether or not to start packet transmission, and waits until it determines to start packet transmission.
  • step S16 if it is determined to start packet transmission, the process proceeds to step S17, and the controller 60 determines whether or not the data should be transmitted in the extended mode.
  • the controller 60 determines that the data should be transmitted in the extended mode according to the content of the data to be transmitted, for example, if the data is transmitted in a use case of an application example described later. do.
  • step S17 determines in step S17 that the data should be transmitted in the extended mode
  • step S18 in which extended mode transmission processing (see FIG. 12) for transmitting an extended packet corresponding to the extended mode is performed.
  • step S17 determines in step S17 that the data should not be transmitted in the extended mode. If the controller 60 determines in step S17 that the data should not be transmitted in the extended mode, the process proceeds to step S19.
  • step S19 the controller 60 determines whether or not to transmit a short packet. For example, the controller 60 determines to transmit short packets at the start and end of a frame.
  • step S19 determines in step S19 to transmit a short packet
  • the process proceeds to step S20.
  • step S ⁇ b>20 the packet header generator 52 generates a packet header and transmits a short packet having a conventional packet structure to the application processor 22 .
  • step S19 the controller 60 determines in step S19 not to transmit a short packet (that is, to transmit a long packet)
  • the process proceeds to step S21.
  • step S 21 the packing unit 51 stores the image data in the payload, and the CRC calculation unit 57 obtains the CRC to generate a long packet with a conventional packet structure and transmit it to the application processor 22 .
  • step S18 After the process of step S18, step S20, or step S21, the process proceeds to step S22, and the controller 60 ends the packet transmission process. After that, the process returns to step S16, and the process of transmitting the next packet is repeated in the same manner.
  • FIG. 12 is a flowchart for explaining the extension mode transmission process performed in the process of step S18 of FIG.
  • step S ⁇ b>31 the packet header generation unit 52 generates a packet header containing VC, data type, WC, etc., and transmits it to the application processor 22 .
  • step S32 the application processor 22 determines whether or not to transmit an extended short packet. For example, the controller 60 determines to transmit extended short packets at the start and end of a frame.
  • step S32 determines in step S32 to transmit an extended short packet. If the application processor 22 determines in step S32 to transmit an extended short packet, the process proceeds to step S33.
  • step S33 the extended packet header generation unit 53 transmits an extended packet header with the data type (DataType[7:0]) set to short packet at the first byte of the payload.
  • the extended packet header generator 53 performs various settings (for example, OePH[7:0], OePF[3:0], etc.) stored in the extended packet header.
  • step S34 the extended packet header generator 53 stores the frame number (FN: FrameNumber) in the second byte of the payload and transmits it.
  • step S35 the extension packet header generation unit 53 generates and transmits an optional extension packet header as shown in FIG. 4 according to the setting (OePH[7:0]) made in step S33.
  • step S36 the CRC calculator 57 obtains the CRC and transmits it as a packet footer.
  • step S32 determines in step S32 not to transmit the extended short packet (that is, to transmit the long packet). the process proceeds to step S37.
  • step S37 the extended packet header generation unit 53 transmits an extended packet header in which the data type (DataType[7:0]) is set to other than short packet at the first byte of the payload.
  • the extended packet header generator 53 performs various settings (for example, OePH[7:0], OePF[3:0], etc.) stored in the extended packet header.
  • step S38 the extension packet header generation unit 53 generates and transmits an optional extension packet header as shown in FIG. 5 according to the setting (OePH[7:0]) made in step S37.
  • step S39 the packing unit 51 packs the image data supplied from the image processing unit 43, generates a legacy payload, and transmits it.
  • step S40 the extension packet footer generation unit 54 generates and transmits an optional extension packet footer as shown in FIG. 4 according to the setting (OePF[3:0]) made in step S37.
  • step S41 the CRC calculation unit 57 obtains a CRC and transmits it as a packet footer.
  • step S36 or S41 the extended mode transmission process is terminated.
  • the image sensor 21 can generate and transmit extended short packets or extended long packets.
  • FIG. 13 is a flow chart explaining the processing for the application processor 22 to receive packets.
  • the process starts when the image sensor 21 is connected to the application processor 22 via the bus 23 .
  • the controller 74 writes the initial settings of the image sensor 21 (for example, whether to use C-PHY or D-PHY as the physical layer) to the register 73, It is transmitted to the image sensor 21 by the master 72 . This writes the initial settings to the register 47 of the image sensor 21 .
  • step S52 the controller 74 recognizes whether or not the image sensor 21 supports extended mode. For example, the controller 74 acquires a set value (for example, extended PH/PF compatible capability) stored in the register 47 of the image sensor 21 by the I2C/I3C master 72, thereby making the image sensor 21 compatible with the extended mode. It is possible to recognize whether or not Alternatively, the controller 74 can recognize in advance whether the image sensor 21 is compatible with the extension mode, for example, based on manual input.
  • a set value for example, extended PH/PF compatible capability
  • step S53 the controller 74 determines whether the image sensor 21 supports extended mode and whether the application executed by the application processor 22 requests use of the extended mode.
  • step S53 determines in step S53 that the image sensor 21 does not support the extended mode or that the use of the extended mode is not required, the process proceeds to step S54.
  • step S54 the controller 74 sends an image data transmission start command to the image sensor 21 by the I2C/I3C master 72. At this time, the controller 74 also causes the communication settings according to the CSI-2 standard to be transmitted.
  • step S55 the application processor 22 performs conventional packet reception processing for receiving packets having a packet structure conforming to the existing CSI-2 standard, based on the communication settings transmitted in step S54.
  • step S53 determines in step S53 that the image sensor 21 is compatible with the extended mode and that the application executed by the application processor 22 requests the use of the extended mode
  • the process proceeds to step S56. proceed to
  • step S56 the I2C/I3C master 72 transmits fixed communication settings required for communication in extended mode before communication in extended mode is started. As a result, the fixed communication settings are written to the register 47 of the image sensor 21 (step S14 in FIG. 11).
  • step S57 the controller 74 transmits an image data transmission start command to the image sensor 21 by the I2C/I3C master 72. At this time, the controller 74 also causes the communication settings according to the CSI-2 standard to be transmitted.
  • step S58 the packet header detection unit 81 checks the data supplied from the physical layer processing unit 71 to determine whether or not packet reception has started. wait for For example, when the packet header detector 81 detects the packet header from the data supplied from the physical layer processor 71, it determines that packet reception has started.
  • step S58 If the packet header detector 81 determines in step S58 that packet reception has started, the process proceeds to step S59.
  • step S59 if the packet header detector 81 determines that the packet for which reception has started is an extension packet, the process proceeds to step S60, and extension mode reception processing (see FIG. 14) for receiving the extension packet is performed. .
  • step S59 determines in step S59 that the packet that has started receiving is not an extension packet, the process proceeds to step S61.
  • step S61 the packet header detection unit 81 checks the data type (DataType[5:0]) of the packet header detected in step S58, and determines whether or not the packet that has started receiving is a short packet. .
  • step S61 if the packet header detection unit 81 determines that the packet that has started to be received is a short packet, the process proceeds to step S62.
  • step S ⁇ b>62 the packet header detector 81 receives a short packet having a conventional packet structure transmitted from the image sensor 21 .
  • step S61 the process proceeds to step S63.
  • the unpacking unit 87 receives the payload of the long packet of the conventional packet structure transmitted from the image sensor 21, extracts the image data, and the CRC calculation unit 86 extracts the image data following the packet header. Receive the coming WC+1 byte as CRC.
  • step S60 After the process of step S60, step S62, or step S63, the process proceeds to step S64, and the controller 74 ends the packet reception process. After that, the process returns to step S58, and the process of receiving the next packet is repeated in the same manner.
  • FIG. 14 is a flow chart explaining the extension mode reception process performed in the process of step S60 of FIG.
  • step S71 when the packet header detection unit 81 determines that the mode setting of the extension mode is extension mode 0, the process proceeds to step S72.
  • step S72 the interpretation unit 83 receives the first byte of the payload as an extension packet header.
  • step S73 the interpreting unit 83 checks the data type (DataType[7:0]) of the extension packet header received in step S72, and determines whether or not the packet whose reception has started is an extension short packet. .
  • step S73 when the interpretation unit 83 determines that the packet is an extended short packet, the process proceeds to step S74.
  • the interpretation unit 83 receives the optional extension packet header according to the setting (OePH[7:0]) stored in the extension packet header received in step S72.
  • step S75 the CRC calculation unit 86 receives the WC+1-th byte transmitted following the optional extension packet header as a CRC.
  • step S73 determines in step S73 that the packet is not an extended short packet (that is, reception of an extended long packet has started)
  • the process proceeds to step S76.
  • step S76 the interpretation unit 83 receives the optional extension packet header according to the setting (OePH[7:0]) stored in the extension packet header received in step S72.
  • step S77 the unpacking unit 87 receives the legacy payload of the extended long packet transmitted from the image sensor 21 and extracts the image data.
  • step S78 the interpretation unit 83 receives the optional extension packet footer according to the setting (OePF[3:0]) stored in the extension packet header received in step S72.
  • step S79 the CRC calculation unit 86 receives the WC+1-th byte transmitted following the optional extension packet footer as a CRC.
  • step S71 determines whether the mode setting of the extended mode is not extended mode 0 or after the process of step S79.
  • the application processor 22 can receive extended short packets or extended long packets and acquire data.
  • the packet header and packet footer are the same as those of the existing CSI-2 standard, with emphasis on maintaining compatibility with the existing CSI-2 standard.
  • the packet structure is expanded with an extended packet header, an optional extended packet header, and an optional extended packet footer.
  • the packet header and packet footer are different from those of the existing CSI-2 standard, and the extended packet header and extended packet footer are used to extend the packet structure.
  • FIG. 15 shows the packet structure of a short packet (hereafter, extended short packet for D-PHY) used in CSI-2 extended mode when the physical layer is D-PHY.
  • a short packet hereafter, extended short packet for D-PHY
  • the extended short packet for D-PHY shown in FIG. 15 is stored in the same packet header as the existing CSI-2 standard, like the extended short packet for D-PHY of the first structural example shown in FIG.
  • the extended mode is identified by the data type used.
  • a frame number is added to the short packet data field in the next 16 bits of the data type of the packet header, just like the short packet conforming to the existing CSI-2 standard. is stored.
  • an extended packet header configured similarly to the extended packet header shown in FIG. 4 is transmitted.
  • the application processor 22 on the receiving side interprets the data type stored in the extended packet header, and if it is an extended short packet, determines that the frame number is stored in the data field of the packet header. can do.
  • the optional extension packet header in the extension short packet for D-PHY shown in FIG. 15 is configured in the same manner as the optional extension packet header in the extension short packet for D-PHY of the first structural example shown in FIG. be. However, since the optional extension packet header has a packet structure that is not embedded in the payload, there is no need to add a CRC at the end.
  • FIG. 16 shows the packet structure of a long packet (hereinafter, extended long packet for D-PHY) used in CSI-2 extended mode when the physical layer is D-PHY.
  • extended long packet for D-PHY a long packet used in CSI-2 extended mode when the physical layer is D-PHY.
  • the extended data is not embedded in the payload and is transmitted as part of the packet header or packet footer. Therefore, WC in the top packet header indicates the byte length of the payload as in the existing standard.
  • FIG. 17 shows the packet structure of a short packet (hereinafter, extended short packet for C-PHY) used in CSI-2 extended mode when the physical layer is C-PHY.
  • extended short packet for C-PHY a short packet used in CSI-2 extended mode when the physical layer is C-PHY.
  • the extension part of the extension short packet for C-PHY shown in FIG. 17 is transmitted as an extension of the packet header according to the existing CSI-2 standard, the extension part such as the extension packet header is inserted after the frame number. be. And, like the existing CSI-2 standard, the packet header ends with a CRC. Furthermore, the packet structure in which these are transmitted twice with SYNC interposed is the same as the short packet according to the existing CSI-2 standard.
  • FIG. 18 shows the packet structure of a long packet (hereinafter, extended long packet for C-PHY) used in CSI-2 extended mode when the physical layer is C-PHY.
  • extended long packet for C-PHY a long packet used in CSI-2 extended mode when the physical layer is C-PHY.
  • the WC at the top of the packet header indicates the byte length of the payload, as in the existing standard. There is a difference from the extended long packet for C-PHY in the structural example.
  • the extension packet of the second structural example has a packet structure in which the existing packet header and footer are extended without embedding the extension data in the existing payload. Therefore, when adopting the packet structure of the extension packet of the second structure example, compared with the case of adopting the packet structure of the extension packet of the first structure example, the conventionally used communication system It is not possible to minimize the impact that would require change. That is, for example, the existing SerDes transmission circuit 34 requires modification to the SerDes reception circuit 35 (FIG. 2).
  • extension packet of the first structural example it is possible to deal with various applications such as in-vehicle use, and at the same time, it is possible to change the conventionally used communication system.
  • An in-vehicle system can be constructed with minimal impact.
  • extension packet of the second structural example although it is necessary to change the conventionally used communication system, it is possible to support various applications such as in-vehicle use.
  • Each block constituting the image sensor 21 in FIG. 9 and the application processor 22 in FIG. 10 described above is configured to be able to process both D-PHY and C-PHY packets.
  • both a block dedicated to processing D-PHY packets and a block dedicated to processing C-PHY packets may be provided, and the processing may be switched between them. .
  • the D-layer processing block unit 101 has a block that exclusively processes D-PHY packets among the blocks that make up the image sensor 21 in FIG.
  • the C-layer processing block unit 102 has a block exclusively for processing C-PHY packets among the blocks constituting the image sensor 21 in FIG.
  • the switching unit 103 Under the control of the controller 60, the switching unit 103 outputs D-PHY packets generated in the D layer processing block unit 101 when D-PHY is used for the physical layer, and switches C-PHY to the physical layer. When used, switching is performed so that the C-PHY packet generated in the C-layer processing block unit 102 is output.
  • the switching unit 111 performs switching so that packets transmitted from the image sensor 21A are supplied to one of the D-layer processing block unit 112 and the C-layer processing block unit 113 under the control of the controller 74 .
  • the D-layer processing block unit 112 has a block that exclusively processes D-PHY packets among the blocks constituting the application processor 22 in FIG.
  • the C-layer processing block unit 113 has a block dedicated to processing C-PHY packets among the blocks constituting the application processor 22 in FIG.
  • the physical layer to be used can be set between the controller 60 and the controller 74 before starting communication. Then, for example, when D-PHY is used for the physical layer, a D-PHY packet generated in the D layer processing block unit 101 is transmitted via the switching unit 103, and is transmitted via the switching unit 111 to D-PHY. It is supplied to the layer processing block unit 112 and processed. Further, for example, when C-PHY is used for the physical layer, a C-PHY packet generated in the C layer processing block unit 102 is transmitted via the switching unit 103, and is transmitted via the switching unit 111 to C-PHY. It is supplied to the layer processing block unit 113 and processed.
  • extension packets are being considered for use cases such as transmitting higher-definition images (RAW24).
  • RAW6, RAW7, RAW8, RAW10, RAW12, RAW14, RAW16, and RAW20 are defined as data types stored in the packet header according to the existing CSI-2 standard.
  • RAW24 with higher definition as the data type of the extension packet header.
  • extension packets are being considered for application to SmartROI, a technology that transmits only the image area of interest on the screen.
  • an extension packet for example, it is possible to transmit coordinate data of 16 bits or more for each of the X and Y coordinates.
  • GLD is a proposal under consideration in CSI-2 ver3.0.
  • the in-vehicle camera interface has at least a disconnection detection function, and indicates the line number (16 bits) that indicates what line the information is on the screen, SourceID (8 bits) that indicates which camera sent it, and the transmission number. Information such as message counter (16bit) is required. Furthermore, when used in combination with SROI as described above, it is conceivable that these pieces of information are transmitted in units of frames.
  • extension packets it is possible to transmit this information.
  • the image sensor 21 and the application processor 22 have different interfaces, it is necessary to convert packets on the transmission path. . That is, when the physical layer of the image sensor 21 is D-PHY and the physical layer of the application processor 22 is C-PHY, for example, in the SerDes device 26, packets for D-PHY are transferred to C-PHY. need to convert.
  • FIG. 20 is a block diagram showing a configuration example of a communication system 201 adapted to E2E protection as a third embodiment of a communication system to which this technology is applied.
  • the communication system 201 is configured by connecting an image sensor 211, a SerDes device 212, a SerDes device 213, and an application processor 214.
  • FIG. 20 describes the case where the SERDES is A-PHY as an example, it also includes the case of connection using other SERDES standards such as FPD-LINK3.
  • the SERDES standard communication may be performed based on the SERDES standard while maintaining the CIS-2 format (at least Application Specific payload).
  • the physical layer processing units 237 and 247 may include a plurality of other SERDES standard physical layer processing units in addition to A-PHY, and the physical layer processing units can be switched according to the application. can.
  • the image sensor 211 includes an extended mode compatible CSI-2 transmission circuit 221, a physical layer processing unit (hereinafter referred to as a C/D-PHY physical layer processing unit) 222 compatible with C-PHY and/or D-PHY, It has at least a slave (hereinafter referred to as an I2C/I3C slave) 223 compatible with I2C or I3C, or both, and a CCI slave 224 .
  • a C/D-PHY physical layer processing unit hereinafter referred to as a C/D-PHY physical layer processing unit
  • I2C/I3C slave a slave 223 compatible with I2C or I3C, or both
  • the SerDes device 212 includes a CSI-2 receiving circuit 231, a C/D-PHY physical layer processing unit 232, an I2C/I3C master 233, a CCI master 234, a CSI-2 A-PHY packet generation unit 235, a CCI A-PHY It has at least a packet transmission/reception unit 236 and a physical layer processing unit 237 compatible with A-PHY.
  • the SerDes device 212 converts packets for C-PHY or D-PHY into packets for A-PHY, and this conversion is determined based on register settings and the like.
  • the SerDes device 213 includes a CSI-2 transmission circuit 241, a C/D-PHY physical layer processing unit 242, an I2C/I3C slave 243, a CCI slave 244, an A-PHY packet reception unit 245 for CSI-2, an A-PHY for CCI It has at least a packet transmission/reception unit 246 and a physical layer processing unit 247 compatible with A-PHY.
  • the SerDes device 213 converts packets for A-PHY into packets for C-PHY or D-PHY, and this conversion is determined based on register settings and the like.
  • the application processor 214 has at least an extended mode compatible CSI-2 receiver circuit 251 , a C/D-PHY physical layer processing unit 252 , an I2C/I3C master 253 and a CCI master 254 .
  • the communication system 201 is configured in this manner, and an extension packet having the structure described above is transmitted from the image sensor 211 and received by the application processor 214 .
  • an extension packet having the structure described above is transmitted from the image sensor 211 and received by the application processor 214 .
  • the communication system 201 is configured such that the physical layer processing unit 222 of the image sensor 211 supports D-PHY and the physical layer processing unit 252 of the application processor 22 supports C-PHY, E2E protection must be ensured not to be violated.
  • the communication system 201 limits the protection scope of E2E protection to Application Specific payload (hereinafter referred to as AS payload), which is a payload specific to an application, so that it can adapt to E2E protection. That is, the AS payload is used when converting A-PHY packets to C-PHY or D-PHY packets, or when converting C-PHY or D-PHY packets to A-PHY packets. No changes are allowed during conversion.
  • AS payload Application Specific payload
  • Fig. 21 shows an example structure of an extended packet for D-PHY that has been extended to support E2E protection.
  • the AS payload consisting of extended packet header (ePH), packet data, and extended packet footer (ePF) is limited as the protection scope of E2E protection.
  • the extended packet header contains the predetermined information that is required when the scope of E2E protection is limited to the AS payload.
  • a packet count PC Packet Count
  • the packet data has the number of bytes determined by the packet count PC.
  • a virtual channel VC Virtual Channel indicating the number of virtual channels is copied to the existing packet header.
  • FIG. 22 shows an example structure of an extended packet for C-PHY that has been extended to support E2E protection.
  • the extension packet for C-PHY like the extension packet for D-PHY, has an AS payload consisting of an extension packet header (ePH), packet data, and an extension packet footer (ePF) for E2E protection. limited as the scope of protection of Then, in the extension packet header, the packet count PC and virtual channel VC are described as predetermined information required when the scope of E2E protection is limited to the AS payload, similar to the extension packet for D-PHY. .
  • ePH extension packet header
  • ePF extension packet footer
  • Fig. 23 shows an example structure of an extended packet for A-PHY extended to support E2E protection.
  • the AS payload consisting of extended packet header (ePH), packet data, and extended packet footer (ePF) is limited as the protection scope of E2E protection.
  • the communication system 201 converts the D-PHY or C-PHY extension packet transmitted from the image sensor 211 to the SerDes device 212 into the A-PHY extension packet is generated. Therefore, the packet count PC and virtual channel VC are already described in the extension packet header of the extension packet for A-PHY.
  • the communication system 201 can avoid modification of the AS payload on the transmission path and comply with E2E protection.
  • the packet structures shown in FIGS. 21 to 23 can be used by partially replacing the corresponding packets of the packet structures shown in FIGS. 3 to 8 and FIGS. 15 to 18. part is replaced.
  • FIG. 24 is a flowchart for explaining packet transmission/reception processing adapted to E2E protection.
  • processing is started when data to be stored in packet data (for example, image data) is supplied to the extended mode compatible CSI-2 transmission circuit 221 .
  • the extended mode compatible CSI-2 transmission circuit 221 stores the supplied data in packet data.
  • the extended mode compatible CSI-2 transmission circuit 221 generates an extended packet header describing the virtual channel VC and the packet count PC as shown in FIG. 21 or FIG. 22 above.
  • the extension mode compatible CSI-2 transmission circuit 221 adds an extension packet header and an extension packet footer to the packet data to generate an AS payload.
  • step S102 the extension mode compatible CSI-2 transmission circuit 221 generates a C-PHY or D-PHY packet header and a C-PHY or D-PHY packet for the AS payload generated in step S101. By adding a footer, an extension packet for C-PHY or D-PHY is generated. Then, the extension mode compatible CSI-2 transmission circuit 221 transmits extension packets for C-PHY or D-PHY to the SerDes device 212 via the C/D-PHY physical layer processing unit 222 .
  • step S103 in the SerDes device 212, the CSI-2 receiving circuit 231 receives data for C-PHY or D-PHY transmitted from the image sensor 211 in step S102 via the C/D-PHY physical layer processing unit 232. receive extension packets for Then, the CSI-2 receiving circuit 231 acquires the AS payload from which the packet header and the packet footer are removed from the received extension packet, and supplies the AS payload as it is to the CSI-2 A-PHY packet generator 235 .
  • step S104 in the SerDes device 212, the A-PHY packet generator 235 for CSI-2 generates an A-PHY packet header and an A-PHY packet header for the AS payload supplied from the CSI-2 receiver circuit 231.
  • a packet footer is added to generate an extension packet for A-PHY.
  • the CSI-2 A-PHY packet generation unit 235 transmits the extension packet for A-PHY to the SerDes device 213 via the physical layer processing unit 237 corresponding to A-PHY.
  • step S105 in the SerDes device 213, the A-PHY packet reception unit 245 for CSI-2 receives the A-PHY packet transmitted from the SerDes device 212 in step S104 via the physical layer processing unit 247 supporting A-PHY. Receive extension packet for PHY. Then, the CSI-2 A-PHY packet receiving unit 245 acquires the AS payload from the received extension packet with the packet header and packet footer removed, and supplies the AS payload to the CSI-2 transmission circuit 241 as it is.
  • step S106 the CSI-2 transmission circuit 241 receives the C-PHY or D-PHY packet header and the C - By adding a packet footer for PHY or D-PHY, an extension packet for C-PHY or D-PHY is generated. The CSI-2 transmission circuit 241 then transmits the extension packet for C-PHY or D-PHY to the application processor 214 via the C/D-PHY physical layer processing unit 242 .
  • step S107 in the application processor 214, the extension mode compatible CSI-2 receiving circuit 251 is for the C-PHY or Receive extension packets for D-PHY. Then, the extension mode compatible CSI-2 receiving circuit 251 acquires the AS payload from the received extension packet, excluding the packet header and packet footer, and transmits various data stored in the packet data of the AS payload to the subsequent stage. Output to LSI (not shown). After that, the packet transmission/reception processing adapted to E2E protection ends, and the same processing is repeatedly performed for the next extended packet.
  • the communication system 201 can transmit and receive extended packets without altering the AS payload on the transmission path by executing packet transmission and reception processing adapted to E2E protection.
  • packet transmission and reception processing adapted to E2E protection.
  • the physical layer of the image sensor 211 is D-PHY and the physical layer of the application processor 214 is C-PHY, that is, even if the respective interfaces are different. can also adhere to E2E protection.
  • FIG. 25 is a block diagram showing a detailed configuration example of the image sensor 211. As shown in FIG. In the image sensor 211 shown in FIG. 25, the same reference numerals are assigned to the components common to the image sensor 21 shown in FIG. 9, and detailed description thereof will be omitted.
  • the image sensor 211 includes pixels 41, an AD converter 42, an image processing unit 43, a register 47, and a controller 60, similar to the image sensor 21 in FIG.
  • An I2C/I3C slave 223 and a CCI slave 224 included in the image sensor 211 correspond to the I2C/I3C slave 46 and CCI slave 59 in FIG. 9, respectively.
  • the image sensor 211 includes an extension mode compatible CSI-2 transmission circuit 221 and a physical layer processing unit 222.
  • the physical layer processing unit 222 is compatible with A-PHY, C-PHY, and D-PHY. there is
  • the extension mode compatible CSI-2 transmission circuit 221 includes the controller 60 and the CCI slave 224, as well as an AS payload generator 301, a selector 302, an A-PHY packet generator 303, a C-PHY packet generator 304, a D-PHY packet generator. It comprises a unit 305 and a selector 306 .
  • the AS payload generation unit 301 generates an AS payload limited as the protection scope of E2E protection and outputs it to the selector 302.
  • AS payload generator 301 has packing section 311 , extended packet header generator 312 , and extended packet footer generator 313 .
  • the packing unit 311 packs image data supplied from the image processing unit 43 as data to be transmitted, and generates packet data of the number of bytes determined by the packet count PC.
  • the controller 60 can control the number of bytes of packet data generated by the packing unit 311 according to the set value (for example, image size) stored in the register 47 .
  • the extended packet header generation unit 312 generates an extended packet header describing the packet count PC and the virtual channel VC and adds it to the packet data, as described with reference to FIGS. 21 to 23, for example.
  • the extended packet footer generator 313 generates an extended packet footer and adds it to the packet data.
  • Selector 302 selects A-PHY packet generator 303, C-PHY packet generator 304, and D-PHY packet generator 303, C-PHY packet generator 304, and D-PHY packet generator 303, which are provided in parallel, as output destinations of the AS payload supplied from AS payload generator 301, under the control of controller 60.
  • One of the packet generators 305 is selected.
  • the A-PHY packet generator 303 generates an extension packet for A-PHY from the AS payload supplied via the selector 302 and outputs it to the selector 306 .
  • the A-PHY packet generator 303 has an AAL generator 321 , an A-PHY packet header generator 322 , and an A-PHY packet footer generator 323 .
  • the AAL (A-PHY Adaptation Layer) generation unit 321 divides the AS payload generated by the AS payload generation unit 301 into 380-byte units in layers called adaptation layers. Then, the A-PHY packet header generation unit 322 adds the A-PHY packet header to the divided AS payload, and the A-PHY packet footer generation unit 323 adds the A-PHY packet footer. Append.
  • AAL A-PHY Adaptation Layer
  • the C-PHY packet generator 304 generates an extension packet for C-PHY from the AS payload supplied via the selector 302 and outputs it to the selector 306 .
  • the C-PHY packet generator 304 has a C-PHY packet header generator 331 , a C-PHY packet footer generator 332 , and a C-PHY lane distributor 333 .
  • the C-PHY packet header generation unit 331 adds a C-PHY packet header to the AS payload generated by the AS payload generation unit 301, and the C-PHY packet footer generation unit 332 adds a C-PHY packet header to the AS payload. Add packet footer for PHY. Then, the C-PHY lane distribution unit 333 distributes the extension packet for C-PHY to three lanes according to the CSI-2 standard.
  • the D-PHY packet generator 305 generates an extension packet for D-PHY from the AS payload supplied via the selector 302 and outputs it to the selector 306 .
  • the D-PHY packet generator 305 has a D-PHY packet header generator 341 , a D-PHY packet footer generator 342 , and a D-PHY lane distributor 343 .
  • the D-PHY packet header generation unit 341 adds a D-PHY packet header to the AS payload generated by the AS payload generation unit 301, and the D-PHY packet footer generation unit 342 adds a D-PHY packet header to the AS payload. Add packet footer for PHY. Then, the D-PHY lane distribution unit 343 distributes the D-PHY extension packet to four lanes according to the CSI-2 standard.
  • Selector 306 selects A-PHY packet generation section 303, C-PHY packet generation section 304, and D-PHY packet generation section 303, C-PHY packet generation section 304, and D-PHY packet generation section 303, which are provided in parallel, as output sources of extension packets supplied to physical layer processing section 222 under the control of controller 60.
  • One of the packet generators 305 is selected.
  • the physical layer processing section 222 transmits the extension packet for A-PHY on one lane. Further, when an extension packet for C-PHY is supplied from the C-PHY packet generation section 304, the physical layer processing section 222 transmits the extension packet for C-PHY on three lanes. In addition, when the D-PHY packet generation unit 305 supplies the extension packet for the D-PHY, the physical layer processing unit 222 transmits the extension packet for the D-PHY using four lanes.
  • the AS payload generator 301 is sent to the A-PHY packet generator 303, the C-PHY packet generator 304, and the D-PHY packet generator 305 via the selector 302.
  • An extended mode compatible CSI-2 transmission circuit 221 is configured to be connected.
  • the image sensor 211 can generate an AS payload common to the extension packet for A-PHY, the extension packet for C-PHY, and the extension packet for D-PHY in one AS payload generation unit 301. can be done. That is, the A-PHY packet generator 303, the C-PHY packet generator 304, and the D-PHY packet generator 305 can share the AS payload generator 301, thereby reducing the circuit scale. . Therefore, miniaturization of the image sensor 211 can be realized.
  • FIG. 26 is a block diagram showing a detailed configuration example of the application processor 214. As shown in FIG. In addition, in the application processor 214 shown in FIG. 26, the same components as those of the application processor 22 shown in FIG.
  • the application processor 214 is configured with a register 73 and a controller 74, similar to the application processor 22 of FIG. Note that the controller 74 may be realized by software. Also, the I2C/I3C master 253 and the CCI master 254 provided in the application processor 214 correspond to the I2C/I3C master 72 and the CCI master 88 in FIG. 10, respectively.
  • the application processor 214 includes an extended mode compatible CSI-2 receiving circuit 251 and a physical layer processing unit 252.
  • the physical layer processing unit 252 supports A-PHY, C-PHY, and D-PHY. there is
  • the extended mode CSI-2 receiver circuit 251 includes a selector 401, an A-PHY packet receiver 402, a C-PHY packet receiver 403, a D-PHY packet receiver 404, a selector 405, and an AS payload. It is configured with a receiving unit 406 .
  • Selector 401 selects one of A-PHY packet receiver 402, C-PHY packet receiver 403, and D-PHY packet receiver 404 provided in parallel as an output destination of the extension packet supplied from physical layer processor 252. choose one of
  • the A-PHY packet receiving unit 402 receives the extension packet for A-PHY supplied via the selector 401 and outputs it to the selector 405 .
  • the A-PHY packet receiver 402 has an A-PHY packet header interpreter 411 , an A-PHY packet footer verifier 412 , and an AAL processor 413 .
  • the A-PHY packet header interpretation unit 411 interprets the contents described in the A-PHY packet header, performs processing necessary for receiving the extension packet for A-PHY,
  • the packet footer verification unit 412 for A-PHY verifies the presence or absence of an error using the packet footer for A-PHY.
  • the AAL processing unit 413 performs processing to combine the AdaptationLayers divided by the AAL generation unit 321 in FIG. 25 .
  • the C-PHY packet receiving unit 403 receives the extension packet for C-PHY supplied via the selector 401 and outputs it to the selector 405 .
  • the C-PHY packet receiving unit 403 has a C-PHY lane merging unit 421 , a C-PHY packet header interpreting unit 422 , and a C-PHY packet footer verifying unit 423 .
  • the C-PHY lane merging unit 421 merges extension packets for C-PHY distributed to three lanes according to the CSI-2 standard and supplied via the physical layer processing unit 252 . Then, the C-PHY packet header interpretation unit 422 interprets the content described in the C-PHY packet header, performs processing necessary for receiving the extension packet for the C-PHY, The packet footer verification unit 423 for C-PHY verifies the presence or absence of an error using the packet footer for C-PHY.
  • the D-PHY packet receiving unit 404 receives the extension packet for D-PHY supplied via the selector 401 and outputs it to the selector 405 .
  • the D-PHY packet reception unit 404 has a D-PHY lane merge unit 431 , a D-PHY packet header interpretation unit 432 , and a D-PHY packet footer verification unit 433 .
  • the D-PHY lane merging unit 431 merges D-PHY extension packets distributed to four lanes according to the CSI-2 standard and supplied via the physical layer processing unit 252 . Then, the D-PHY packet header interpretation unit 432 interprets the contents described in the D-PHY packet header, performs processing necessary for receiving the D-PHY extension packet, The packet footer verification unit 433 for D-PHY verifies the presence or absence of an error using the packet footer for D-PHY.
  • Selector 405 selects one of A-PHY packet receiver 402, C-PHY packet receiver 403, and D-PHY packet receiver 404, which are provided in parallel, as an output source of the extension packet supplied to AS payload receiver 406. choose one of
  • the AS payload receiving section 406 has an unpacking section 441, an extended packet header interpreting section 442, and an extended packet footer verifying section 443 corresponding to the AS payload generating section 301 in FIG.
  • the unpacking unit 441 unpacks the image data packed by the packing unit 311 .
  • the extended packet header interpreter 442 interprets the extended packet header generated by the extended packet header generator 312, and reads, for example, the packet count PC and the virtual channel VC.
  • the extended packet footer verification unit 443 uses the extended packet footer added by the extended packet footer generation unit 313 to verify the presence or absence of an error. Then, the AS payload receiving unit 406 receives various data stored in the packet data supplied via the selector 405, such as image data, vehicle row number, SourceID, CRC error, etc. not shown).
  • the AS payload receiver 406 is sent to the A-PHY packet receiver 402, the C-PHY packet receiver 403, and the D-PHY packet receiver 404 via the selector 405.
  • the extension mode compatible CSI-2 receiving circuit 251 is configured to be connected.
  • the application processor 214 receives the AS payload common to the extension packet for A-PHY, the extension packet for C-PHY, and the extension packet for D-PHY in one AS payload receiving section 406. can be done. That is, the AS payload receiver 406 can be shared by the A-PHY packet receiver 402, the C-PHY packet receiver 403, and the D-PHY packet receiver 404, thereby reducing the circuit scale. . Therefore, miniaturization of the application processor 214 can be achieved.
  • a communication system 501 shown in FIG. 27 has a direct connection configuration in which an image sensor 511 and an application processor 512 are directly connected by A-PHY (without going through a SerDes device as described later with reference to FIG. 40). It's becoming
  • the image sensor 511 comprises an A-PHY processing unit 521, a CSIA processing unit 522, a CSI2 processing unit 523, a CSI2-FS processing unit 524, a CCI processing unit 525, a CCI-FS processing unit 526, and a register 527. .
  • the A-PHY processing unit 521 has a CCI processing unit 525 mounted as an upper layer, and is connected to the A-PHY processing unit 531 of the application processor 512 via MIPI A-PHY to process data including the extended packet header ePH and the extended packet footer ePF. send and receive
  • the CCI-FS processing unit 526 compares the Destination ID included in the extended packet header ePH with the ID (Source ID) of the image sensor 511, and determines whether or not the image sensor 511 is accessed.
  • the application processor 512 includes an A-PHY processing unit 531, a CSIA processing unit 532, a CSI2 processing unit 533, a CSI2-FS processing unit 534, a CCI processing unit 535, a CCI-FS processing unit 536, a register 537, and a CCI-FS switch 538. configured with
  • the A-PHY processing unit 531 has a CCI processing unit 535 mounted as an upper layer, and is connected to the A-PHY processing unit 521 of the image sensor 511 via MIPI A-PHY to process data including the extended packet header ePH and the extended packet footer ePF. send and receive
  • the CCI-FS processing unit 536 compares the Destination ID included in the extended packet header ePH with the ID (Source ID) possessed by the application processor 512, and determines whether or not the application processor 512 is accessed.
  • the CCI-FS switch 538 transmits/receives data via the CCI-FS processing unit 536 when the CCI-FS processing unit 536 is enabled, and transmits/receives data via the CCI-FS processing unit 536 when the CCI-FS processing unit 536 is disabled. Switching is performed so that data is transmitted and received without going through the processing unit 536 .
  • FIG. 28 shows an example of a read command packet configuration generated in the CCI-FS processing unit 536 of the application processor 512 during read access.
  • Extended packet header ePH0 stores extended VC, extended DT, extended PFEN, and extended PHEN.
  • the extended DT is information indicating the CCI protocol (I2C), and routing processing is performed using the extended DT.
  • Source ID[7:1] and Packet Length are stored in the extended packet header ePH1.
  • the Source ID is information indicating the source of the CCI protocol (I2C), and response processing is performed based on the Source ID.
  • Packet Length is information indicating the data length.
  • Security Descriptor and Message Counter are stored in the extended packet header ePH2.
  • Security Descriptor indicates whether or not security is used, and indicates "8'h0" when security is not used.
  • MessageCounter is information indicating the bucket order, and indicates a count value obtained by counting messages, and indicates "16'h5" when the message is the fifth.
  • Destination ID[7:1], Read/Write, and DestinationAddress are stored in the extended packet header ePH3.
  • Destination ID[7:1] indicates the slave address of the CCI processing unit 525 of the image sensor 511, which is "7'h0D" in the illustrated example.
  • the Destination ID is information indicating the destination of the CCI protocol (I2C), and routing is performed based on the Destination ID, and the communication path is referenced.
  • Read/Write indicates reading or writing of data, and indicates "1'b1" in the case of read.
  • Destination Address indicates the address of the register 527 of the image sensor 511, which is the final destination, and is "0x0200" in the illustrated example.
  • various data are stored in the AP (CCI) payload.
  • the AP (CCI) payload may not be sent when security is off, and dummy data may be stored and sent when security is on.
  • the extended packet footer ePF1 is not sent when security is off.
  • the CRC calculation value is stored in the extended packet footer ePF0.
  • such a packet-structured read command is generated in the CCI-FS processing unit 536 and supplied to the A-PHY processing unit 531 .
  • FIG. 29 shows an example of the packet configuration of a read command output from the A-PHY processing unit 531 of the application processor 512 during read access.
  • the A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to the read command supplied from the CCI-FS processing unit 536 as the protection range of E2E protection.
  • a read command with such a packet structure is A-PHY transferred by the APHY processing unit 531 of the application processor 512 . Then, in the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer from the read command. After that, the read command is supplied to the CCI-FS processing section 526 via the CCI processing section 525 of the slave address "7'h0D" indicated by the Destination ID.
  • FIG. 30 shows an example of the read command supplied to the CCI-FS processing unit 526 and the packet structure of the read data generated in the CCI-FS processing unit 526 during read access.
  • the AP (CCI) payload stores the read data value read from the address "0x0200" of the register 527 indicated by the source address information (Destination Address) of the extended packet header ePH of the read command.
  • such packet-structured read data is generated in the CCI-FS processing unit 526 and supplied to the A-PHY processing unit 521 .
  • FIG. 31 shows an example of the packet configuration of read data output from the A-PHY processing unit 521 of the image sensor 511 during read access.
  • the A-PHY processing unit 521 adds an A-PHY header and an A-PHY footer to the read data supplied from the CCI-FS processing unit 526 as the protected range of E2E protection.
  • the read data with such a packet structure is A-PHY transferred by the A-PHY processing unit 521 of the image sensor 511 . Then, in the application processor 512 , the A-PHY processing unit 531 removes the A-PHY header and A-PHY footer from the read data, and the read data is supplied to the CCI-FS processing unit 536 .
  • FIG. 32 shows an example of the packet structure of read data supplied to the CCI-FS processing unit 536 during read access.
  • the read data with the packet structure shown in FIG. 30 as it is, that is, the read data within the protection range of E2E Protection in A-PHY transfer is supplied to the CCI-FS processing unit 536.
  • FIG. 33 shows an example of the packet configuration of write data generated in the CCI-FS processing unit 536 of the application processor 512 during write access.
  • Extended packet header ePH0 stores extended VC, extended DT, extended PFEN, and extended PHEN.
  • Source ID[7:1] and Packet Length are stored in the extended packet header ePH1.
  • Security Descriptor and Message Counter are stored in the extended packet header ePH2.
  • Security Descriptor indicates whether or not security is used, and indicates "8'h0" when security is not used.
  • MessageCounter indicates a count value obtained by counting messages, and indicates "16'h4" when the message is the fourth.
  • Destination ID[7:1], Read/Write, and DestinationAddress are stored in the extended packet header ePH3.
  • Destination ID[7:1] indicates the slave address of the CCI processing unit 525 of the image sensor 511, which is "7'h0D" in the illustrated example.
  • Read/Write indicates reading or writing of data, and indicates "1'b0" in the case of writing.
  • Destination Address indicates the address of the register 527 of the image sensor 511, which is the final destination, and is "0x1234" in the illustrated example.
  • the data (Data0[7:0]) to be written to the image sensor 511 is stored in the AP (CCI) payload, and the 0xFF value is the write data.
  • the extended packet footer ePF1 is not sent when security is off.
  • the CRC calculation value is stored in the extended packet footer ePF0.
  • such packet-structured write data is generated in the CCI-FS processing unit 536 and supplied to the A-PHY processing unit 531 .
  • FIG. 34 shows an example of the packet configuration of write data output from the A-PHY processing unit 531 of the application processor 512 during write access.
  • the A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to the write data supplied from the CCI-FS processing unit 536 as the protection range of E2E protection.
  • Write data with such a packet structure is A-PHY transferred by the A-PHY processing unit 531 of the application processor 512 . Then, in the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer from the write data. After that, the write data is supplied to the CCI-FS processing section 526 via the CCI processing section 525 of the slave address "7'h0D" indicated by the Destination ID.
  • FIG. 35 shows an example of the packet structure of write data supplied to the CCI-FS processing unit 526 during write access.
  • the write data with the packet structure shown in FIG. 33 as it is, that is, the write data set as the protection range of E2E Protection in A-PHY transfer, is supplied to the CCI-FS processing unit 526. Then, the CCI-FS processing unit 526 selects the AP (CCI) payload from the address "0x1234" of the register 527 indicated by the CCI command ID information, that is, the source address information (Destination Address) of the extended packet header ePH of the read command. Write stored data.
  • CCI AP
  • the extended packet header ePH uses fields such as extended VC, extended DT, and Message Counter.
  • the length of the extended packet header ePH can be changed with the field value (epFEN field) of the extended packet header ePH.
  • Length Packet Length(PL) x Data Byte Width.
  • the length of the extended packet footer ePF1 can be changed with the field setting value (epFEN field) of the extended packet header ePH. Also, security-related information can be added.
  • the extended packet footer ePF0 can add a CRC-32 calculated from the packet data with the field setting value of the extended packet header ePH.
  • initial setting and confirmation operations are performed in steps S211 to S222.
  • step S211 read access is made twice to the Capability register of the CCI-FS processing unit 526 from the application processor 512 to the image sensor 511.
  • the number of read accesses is not limited to two, and can be set arbitrarily for functional safety, and may be one or more than three times.
  • step S212 in the application processor 512, the CSI2-FS processing unit 524 checks whether or not the Capability register value of the CCI-FS processing unit 526 is 1'b1 both times for the result of the read access in step S211. judge. If it is determined in step S212 that the Capability register value of the CCI-FS processing unit 526 is not 1'b1 both times, the process proceeds to step S213.
  • step S213 in the application processor 512, the CSI2-FS processing unit 524 determines whether or not the number of retransmissions is three or more. Note that the number of retransmissions is not limited to three, and can be set to any number, and the same applies to the number of retransmissions described below. If it is determined in step S213 that the number of retransmissions is not three or more (one or two), the process returns to step S211, and the same process is repeated thereafter.
  • step S212 determines whether the Capability register value of the CCI-FS processing unit 526 is 1'b1 both times. If it is determined in step S212 that the Capability register value of the CCI-FS processing unit 526 is 1'b1 both times, the process proceeds to step S214.
  • step S214 one write access to the Enable register of the CCI-FS processing unit 526 is performed from the application processor 512 to the image sensor 511.
  • step S215 in the image sensor 511, the CCI-FS processing unit 526 performs one write access to the Enable register of the CCI-FS processing unit 536 of the application processor 512.
  • step S216 the slave address of the opposing image sensor 511 is set in the Destination SID register of the CCI-FS processing unit 536 of the application processor 512.
  • step S217 the ePH register of the CCI-FS processing unit 536 of the application processor 512 is set.
  • step S218 the ePH register of the CCI-FS processing unit 526 is set from the application processor 512 to the image sensor 511.
  • step S219 read access to the Enable register and Error register of the CCI-FS processing unit 526 is made from the application processor 512 to the image sensor 511.
  • step S220 in the application processor 512, the CCI-FS processing unit 536 confirms that the Enable register value of the CCI-FS processing unit 526 is 1'b1 and the Error register value is It is determined whether or not it is 0.
  • step S220 If it is determined in step S220 that the Enable register value of the CCI-FS processing unit 526 is not 1'b1 or the Error register value is not 0, the process proceeds to step S221.
  • step S221 in the application processor 512, the CSI2-FS processing unit 524 determines whether or not the number of retransmissions is three or more. If it is determined in step S221 that the number of retransmissions is three or more, the process returns to step S211, and the same process is repeated thereafter.
  • step S213 determines whether the number of retransmissions is 3 or more, or if it is determined in step S221 that the number of retransmissions is not 3 or more (one or two times). If it is determined in step S213 that the number of retransmissions is 3 or more, or if it is determined in step S221 that the number of retransmissions is not 3 or more (one or two times), the process proceeds to step S222. proceed to
  • step S222 CCI communication is performed without using CCI-FS, after which the communication process is terminated.
  • step S220 determines whether the Enable register value of the CCI-FS processing unit 526 is 1'b1 and the Error register value is 0, the process proceeds to step S223.
  • steps S223 to S234 a write operation using CCI-FS is performed.
  • step S223 the CCI-FS processing unit 536 of the application processor 512 sets the ePH register so that the write operation is performed.
  • step S224 the CCI-FS processing unit 536 of the application processor 512 sets the write data register.
  • step S225 the CCI-FS processing unit 536 of the application processor 512 sets the command execution register to 1.
  • step S226, in the application processor 512, the A-PHY processing unit 531 treats the write data generated by the CCI-FS processing unit 536 as the protection range of E2E Protection as shown in FIG. Add header and A-PHY footer and perform A-PHY transfer.
  • step S227 in the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer from the write data, and supplies the protection range of E2E protection to the CCIFS processing unit 526.
  • step S229 in the image sensor 511, the CCI-FS processing unit 526 determines whether the Source ID of the image sensor 511 confirmed in step S228 matches the Destination SID of the extension packet header ePH.
  • step S229 If it is determined in step S229 that the Source ID of the image sensor 511 matches the Destination SID of the extended packet header ePH, the process proceeds to step S230.
  • step S230 in the image sensor 511, the CCI-FS processing unit 526 confirms the Message Counter from the content of the extended packet header ePH.
  • step S231 in the image sensor 511, the CCI-FS processing unit 526 determines whether or not the Message Counter (reception) of the image sensor 511 confirmed in step S230 matches the Message Counter of the extension packet header ePH. .
  • step S231 If it is determined in step S231 that the Message Counter (reception) of the image sensor 511 matches the Message Counter of the extended packet header ePH, the process proceeds to step S232.
  • step S232 in the image sensor 511, the CCI-FS processing unit 526 confirms the CRC from the contents of the extended packet footer ePF.
  • step S233 in the image sensor 511, the received value (ePF0) of the extension packet footer ePF confirmed in step S232 by the CCI-FS processing unit 526 matches the CRC calculation result calculated in the CCI-FS processing unit 526. Determine whether or not
  • step S233 If it is determined in step S233 that the received value (ePF0) of the extension packet footer ePF matches the CRC calculation result, the process proceeds to step S234.
  • step S234 in the image sensor 511, the CCI-FS processing unit 526 performs write processing to write write data to the address of the register 527 from the contents of the extended packet header ePH and the extended packet footer ePF. After that, the process proceeds to step S235.
  • steps S235 to S247 a read operation using CCI-FS is performed.
  • step S235 in the application processor 512, the CCI-FS processing unit 536 sets the ePH register so that a read operation is performed.
  • step S236 in the application processor 512, the CCI-FS processing unit 536 sets the command execution register to 1.
  • step S237 in the application processor 512, the A-PHY processing unit 531 converts the write data generated by the CCI-FS processing unit 536 into the protection range of E2E Protection as shown in FIG. Add header and A-PHY footer and perform A-PHY transfer.
  • step S238 in the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer from the write data and supplies the protection range of E2E protection to the CCI-FS processing unit 526.
  • step S239 in the image sensor 511, the CCI-FS processing unit 526 confirms the Source ID of the image sensor 511 and the Destination SID of the extension packet header ePH from the content of the extension packet header ePH.
  • step S240 in the image sensor 511, the CCI-FS processing unit 526 determines whether the Source ID of the image sensor 511 confirmed in step S239 matches the Destination SID of the extension packet header ePH.
  • step S240 If it is determined in step S240 that the Source ID of the image sensor 511 matches the Destination SID of the extended packet header ePH, the process proceeds to step S241.
  • step S241 in the image sensor 511, the CCI-FS processing unit 526 confirms the Message Counter from the content of the extended packet header ePH.
  • step S242 in the image sensor 511, the CCI-FS processing unit 526 determines whether or not the Message Counter (reception) of the image sensor 511 confirmed in step S241 matches the Message Counter of the extension packet header ePH. .
  • step S242 If it is determined in step S242 that the Message Counter (reception) of the image sensor 511 matches the Message Counter of the extended packet header ePH, the process proceeds to step S243.
  • step S243 in the image sensor 511, the CCI-FS processing unit 526 confirms the CRC from the content of the extended packet footer ePF.
  • step S244 in the image sensor 511, the received value (ePF0) of the extension packet footer ePF confirmed by the CCI-FS processing unit 526 in step S243 matches the CRC calculation result calculated in the CCI-FS processing unit 526. Determine whether or not
  • step S244 If it is determined in step S244 that the received value (ePF0) of the extension packet footer ePF matches the CRC calculation result, the process is terminated.
  • step S229 of FIG. 38 or step S240 of FIG. 39 the process proceeds to step S245.
  • step S245 the Error register (Routing) on the image sensor 511 side is set to 1, after which the process ends.
  • step S231 of FIG. 38 or step S242 of FIG. 39 determines whether the Message Counter (reception) of the image sensor 511 matches the Message Counter of the extension packet header ePH.
  • step S246 the Error register (MC) on the image sensor 511 side is set to 1, after which the process ends.
  • step S233 of FIG. 38 or step S244 of FIG. 39 determines whether the received value (ePF0) of the extension packet footer ePF and the CRC calculation result do not match.
  • step S247 the Error register (CRC) on the image sensor 511 side is set to 1, and then the process is terminated.
  • CRC Error register
  • a communication system 601 shown in FIG. 40 has a SerDes connection configuration in which an image sensor 611 and an application processor 614 are connected via a SerDes device 612 on the slave side and a SerDes device 613 on the master side.
  • the image sensor 611 comprises an I2C/I3C slave 621, a CCI processing section 622, a CSI2-FS processing section 623, and a register 624.
  • the slave-side SerDes device 612 includes an A-PHY processing unit 631, a CSIA processing unit 632, a CSI2-FS processing unit 633, an I2C/I3C master 634, a CCI processing unit 635, a CCI-FS processing unit 636, and a register 637. consists of
  • the master-side SerDes device 613 includes an A-PHY processing unit 641, a CSIA processing unit 642, a CSI2-FS processing unit 643, an I2C/I3C slave 644, a CCI processing unit 645, a CCI-FS processing unit 646, and a register 647. consists of
  • the application processor 614 comprises an I2C/I3C master 651, a CCI processing unit 652, a CCIFS processing unit 653, a register 654, and a CCI-FS switch 655.
  • FIG. 41 shows an example of the packet configuration of a read command generated by the CCI-FS processing unit 653 of the application processor 614 during read access.
  • such a packet-structured read command is generated in the CCI-FS processing unit 653 and supplied to the I2C/I3C master 651 .
  • FIG. 42 shows an example of the packet configuration of a read command output from the I2C/I3C master 651 of the application processor 614 during read access.
  • the I2C/I3C master 651 sends a connection destination sensor address, that is, in the configuration shown in FIG. Address+W 8-bit).
  • the register addresses (RegisterAddress[15:8] and RegisterAddress[7:0]) of register 647 of SerDes device 613 on the master side are sent.
  • a read command with such a packet structure is transferred from the I2C/I3C master 651 of the application processor 614 by I2C/I3C.
  • FIG. 43 shows an example of the packet configuration of a read command output from the A-PHY processing section 641 of the SerDes device 613 on the master side during read access.
  • the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the read command acquired by the I2C/I3C slave 644 as the protection range of E2E Protection.
  • a read command with such a packet structure is A-PHY transferred by the A-PHY processing unit 641 of the SerDes device 613 on the master side.
  • the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer from the read command.
  • the read command is supplied to the CCI processing unit 635 of the slave address "7'h0E" indicated by the Destination ID via the CSIA processing unit 632, CSI2-FS processing unit 633, and CCI-FS processing unit 636, the I2C /I3C master 634.
  • FIG. 44 shows an example of the packet configuration of the read command output from the I2C/I3C master 634 during read access.
  • the I2C/I3C master 634 sends the sensor address of the connection destination, that is, the address of the CCI processing unit 622 of the image sensor 611 in the configuration shown in FIG. 8-bit).
  • the register addresses of registers 624 of image sensor 611 (Register Address [15:8] and Register Address [7:0]) are sent.
  • FIG. 45 shows an example of the read command supplied to the CSI2-FS processing unit 623 and the packet structure of the read data generated in the CSI2-FS processing unit 623 during read access.
  • the read command with the packet structure shown in FIG. 41 as it is, that is, the read command with the protection range of E2E Protection in the APHY transfer is supplied to the CSI2-FS processing unit 623.
  • the AP (CCI) payload stores the read data value read from the address "0x0200" of the register 624 indicated by the source address information (Destination Address) of the extended packet header ePH of the read command.
  • such packet-structured read data is generated in the CCI-FS processing unit 623 and supplied to the I2C/I3C slave 621 via the CCI processing unit 622 .
  • FIG. 46 shows an example of the packet configuration of read data output from the I2C/I3C slave 621 of the image sensor 611 during read access.
  • the I2C/I3C slave 621 sends the sensor address of the connection destination, that is, the address of the I2C/I3C master 634 of the SerDes device 612 on the slave side in the configuration shown in FIG. Send Slave Address+W 8-bit).
  • the read data storage address (the address of the register 624 of the image sensor 611) is sent, and the address (Slave Address+R 8-bit) of the I2C/I3C master 634 of the SerDes device 612 on the slave side is sent. be done.
  • the stop condition P is transmitted.
  • a read command with such a packet structure is transferred from the I2C/I3C slave 621 of the image sensor 611 by I2C/I3C.
  • FIG. 47 shows an example of the packet configuration of read data output from the A-PHY processing section 631 of the SerDes device 612 on the slave side during read access.
  • the A-PHY processing unit 631 adds an A-PHY header and an A-PHY footer to the read data acquired by the I2C/I3C master 634 as the protected range of E2E protection.
  • the read data with such a packet structure is A-PHY transferred by the A-PHY processing unit 631 of the SerDes device 612 on the slave side. Then, in the SerDes device 613 on the master side, the A-PHY processing unit 641 removes the A-PHY header and A-PHY footer from the read data. Read data is supplied to the I2C/I3C slave 644 via the CSIA processing unit 642 , CSI2-FS processing unit 643 , CCI-FS processing unit 646 and CCI processing unit 635 .
  • FIG. 48 shows an example of the packet configuration of read data output from the I2C/I3C slave 644 of the SerDes device 613 on the master side during read access.
  • the I2C/I3C slave 644 sends the connection destination sensor address, that is, in the configuration shown in FIG. Send Slave Address+W 8-bit).
  • the register address (Register Address [15:8] and Register Address [7:0]) of the register 647 of the SerDes device 613 on the master side is transmitted, and the address of the CCI processing unit 635 (Slave Address+R 8-bit) is transmitted.
  • FIG. 49 shows an example of the packet structure of read data supplied to the CCI-FS processing unit 653 during read access.
  • initial setting and confirmation operations are performed in steps S301 to S317.
  • step S301 the slave address of the opposing image sensor 611 is set in the Destination SID register of the CCI-FS processing unit 653 of the application processor 614.
  • step S302 the ePH register of the CCI-FS processing unit 653 of the application processor 614 is set.
  • step S303 the Destination SID of the Bridge configuration of the CCI-FS processing unit 653 of the application processor 614 is set, and the SerDes device 613 on the master side is registered.
  • the Address, attribution, and Timeout_no1 registers are also set in the same manner, and the same setting is performed thereafter.
  • step S304 the ePH register of the CCI-FS processing unit 643 is set from the application processor 614 to the SerDes device 613 on the master side.
  • step S305 the Destination SID of the bridge configuration of the CCI-FS processing unit 643 is set from the application processor 614 to the master-side SerDes device 613, and the slave-side SerDes device 612 is registered.
  • step S306 read access to the Error register of the CCI-FS processing unit 643 is made from the application processor 614 to the SerDes device 613 on the master side.
  • step S307 in the application processor 614, the CCI-FS processing unit 653 determines whether the register value of the Error register of the CCIFS processing unit 643 of the master-side SerDes device 613 is 0 as a result of the read access in step S306. judge.
  • step S307 If it is determined in step S307 that the register value of the Error register of the CCI-FS processing unit 643 of the SerDes device 613 on the master side is not 0 (other than 0), the process proceeds to step S308.
  • step S308 in the application processor 614, the CCI-FS processing unit 653 determines whether or not the number of retransmissions is 3 or more. , the process returns to step S304, and the same process is repeated thereafter.
  • step S307 if it is determined in step S307 that the register value of the Error register of the CCI-FS processing unit 643 of the master-side SerDes device 613 is 0, the process proceeds to step S309.
  • step S309 the ePH register of the CCI-FS processing unit 636 is set from the application processor 614 to the SerDes device 612 on the slave side.
  • step S310 the Destination SID of the bridge configuration of the CCI-FS processing unit 636 is set from the application processor 614 to the slave-side SerDes device 612, and the slave-side SerDes device 612 is registered.
  • step S311 read access to the Error register of the CCI-FS processing unit 636 is made from the application processor 614 to the SerDes device 612 on the slave side.
  • step S312 in the application processor 614, the CCI-FS processing unit 653 determines whether the register value of the Error register of the CCI-FS processing unit 636 of the slave-side SerDes device 612 is 0 as a result of the read access in step S311. determine whether
  • step S312 If it is determined in step S312 that the register value of the Error register of the CCI-FS processing unit 636 of the slave-side SerDes device 612 is not 0 (other than 0), the process proceeds to step S313.
  • step S313 in the application processor 614, the CCI-FS processing unit 653 determines whether or not the number of retransmissions is 3 or more. , the process returns to step S309, and the same process is repeated thereafter.
  • step S312 determines whether the register value of the Error register of the CCI-FS processing unit 636 of the slave-side SerDes device 612 is 0, the process proceeds to step S314.
  • step S314 the ePH register of the CCI-FS processing unit 623 is set from the application processor 614 to the image sensor 611.
  • step S315 read access to the Error register of the CCI-FS processing unit 623 is made from the application processor 614 to the image sensor 611.
  • step S316 in the application processor 614, the CCI-FS processing unit 653 determines whether or not the register value of the Error register of the CCI-FS processing unit 623 of the image sensor 611 is 0 as a result of the read access in step S315. do.
  • step S316 If it is determined in step S316 that the register value of the Error register of the CCI-FS processing unit 623 of the image sensor 611 is not 0 (other than 0), the process proceeds to step S317.
  • step S317 in the application processor 614, the CCI-FS processing unit 653 determines whether or not the number of retransmissions is 3 or more. , the process returns to step S314, and the same process is repeated thereafter.
  • step S308 if it is determined in step S308, step S313, or step S317 that the number of retransmissions is three or more, the process returns to step S301, and the same process is repeated thereafter.
  • step S316 determines whether the register value of the Error register of the CCI-FS processing unit 623 of the image sensor 611 is 0, the process proceeds to step S318.
  • steps S318 to S327 a write operation using CCI-FS is performed.
  • step S318 the CCI-FS processing unit 653 of the application processor 614 sets the ePH register so that the write operation is performed.
  • step S319 the CCI-FS processing unit 653 of the application processor 614 sets the write data register.
  • step S320 the CCI-FS processing unit 653 of the application processor 614 sets the command execution register to 1 and issues a write command.
  • step S321 the application processor 614 performs Sequence A_Write (during AP) processing, which will be described later with reference to FIG.
  • step S322 the master-side SerDes device 613 performs Sequence B (for SerDes (Master)) processing, which will be described later with reference to FIG.
  • FIG. 56 illustrates the Sequence B (SerDes (Slave)) processing executed by the SerDes device 612 on the slave side, similar processing is also executed by corresponding blocks in the SerDes device 613 on the master side. can do.
  • step S323 the A-PHY processing unit 641 extracts the A-PHY header and A -Add PHY footer and perform A-PHY transfer.
  • step S324 the SerDes device 612 on the slave side performs Sequence B (for SerDes (Slave)) processing, which will be described later with reference to FIG.
  • step S325 the SerDes device 612 on the slave side performs Sequence A_Write (at the time of SerDes (Slave)) processing, which will be described later with reference to FIG.
  • FIG. 53 describes the Sequence A_Write (during AP) processing executed by the application processor 614, similar processing can be executed by corresponding blocks in the SerDes device 612 on the slave side as well.
  • step S326 the image sensor 611 performs Sequence B (for Image Sensor) processing, which will be described later with reference to FIG.
  • FIG. 56 illustrates the Sequence B (SerDes (Slave)) processing executed by the SerDes device 612 on the slave side
  • the image sensor 611 can also execute similar processing by corresponding blocks. can.
  • step S327 in the image sensor 611, the CCI-FS processing unit 623 performs write processing to write write data to the address of the register 624 based on the contents of the extended packet header ePH and the extended packet footer ePF. After that, the process proceeds to step S328.
  • steps S328 to S344 a read operation using CCI-FS is performed.
  • step S328 the CCI-FS processing unit 653 of the application processor 614 sets the ePH register to perform read operation.
  • step S329 the CCI-FS processing unit 653 of the application processor 614 sets the read data register.
  • step S330 the CCI-FS processing unit 653 of the application processor 614 sets the command execution register to 1 and issues a read command.
  • step S331 the application processor 614 performs Sequence A_Read_CMD (during AP) processing, which will be described later with reference to FIG.
  • Sequence A_Read_CMD (during AP) process
  • two branched processes are performed in parallel, the process proceeds to step S332 according to branch A, and the process proceeds to step S339 according to branch B.
  • step S332 the master-side SerDes device 613 performs Sequence B (for SerDes (Master)) processing, which will be described later with reference to FIG.
  • FIG. 56 illustrates the Sequence B (SerDes (Slave)) processing executed by the SerDes device 612 on the slave side, similar processing is also executed by corresponding blocks in the SerDes device 613 on the master side. can do.
  • step S333 the A-PHY processing unit 641 extracts the A-PHY header and A -Add PHY footer and perform A-PHY transfer.
  • step S334 the SerDes device 612 on the slave side performs Sequence B (for SerDes (Slave)) processing, which will be described later with reference to FIG.
  • step S355 the SerDes device 612 on the slave side performs Sequence A_Read_CMD (for SerDes (Slave)) processing, which will be described later with reference to FIG.
  • FIG. 54 describes the Sequence A_Read_CMD (during AP) processing executed in the application processor 614, similar processing can also be executed by corresponding blocks in the slave-side SerDes device 612.
  • the Sequence A_Read_CMD (SerDes (Slave)) process of the two branched processes, the process does not proceed to branch A, and the process proceeds to step S336 according to branch B.
  • step S336 the SerDes device 612 on the slave side performs Sequence A_Read_Data (for SerDes (Slave)) processing, which will be described later with reference to FIG.
  • FIG. 57 describes the Sequence A_Read_Data (during AP) processing executed in the application processor 614, the same processing can be executed by corresponding blocks in the SerDes device 612 on the slave side.
  • step S337 the A-PHY processing unit 631 extracts the A-PHY header and A -Add PHY footer and perform A-PHY transfer.
  • step S3308 the master-side SerDes device 613 performs Sequence B (for SerDes (Master)) processing, which will be described later with reference to FIG.
  • FIG. 56 illustrates the Sequence B (SerDes (Slave)) processing executed in the SerDes device 612 on the slave side, the same processing is performed by corresponding blocks in the SerDes device 613 on the master side. can be executed.
  • step S339 the application processor 614 performs Sequence A_Read_Data (during AP) processing, which will be described later with reference to FIG.
  • step S340 the application processor 614 performs Sequence B (during AP) processing, which will be described later with reference to FIG.
  • FIG. 56 illustrates the Sequence B (SerDes (Slave)) processing executed in the SerDes device 612 on the slave side, but the application processor 614 can also execute similar processing by corresponding blocks. can be done.
  • step S341 in the application processor 614, the CCI-FS processing unit 653 stores read data in the address of the register 654 from the contents of the extended packet header ePH and the extended packet footer ePF.
  • step S342 the image sensor 611, the slave-side SerDes device 612, the master-side SerDes device 613, and the application processor 614 perform error register confirmation for the above-described read processing.
  • step S343 the image sensor 611 and each device (slave-side SerDes device 612, master-side SerDes device 613, and application processor 614) determine whether the register value of the Error register of each CCI-FS processing unit is 0. determine whether or not
  • step S343 If it is determined in step S343 that the register values of all CCI-FS processing units are not 0 (one of them has a register value other than 0), the process proceeds to step S344.
  • step S344 the error-related register values of the CCI-FS processing unit whose register value is not 0 are checked, the Error register is cleared by writing 1, and retransmission processing is performed.
  • step S343 if it is determined in step S343 that the register values of all CCI-FS processing units are 0, or after step S344 is completed, the process ends.
  • FIG. 53 is a flowchart for explaining the Sequence A_Write (during AP) processing performed in step S321 of FIG.
  • the processing performed by the application processor 614 will be described as an example, but the Sequence A_Write (SerDes (Slave)) processing in step S325 of FIG. 51 is performed in the same manner.
  • step S351 in the application processor 614, the I2C/I3C master 651 issues a start command and a slave address (Slave Address+W8-bit shown in FIG. 42).
  • step S352 the application processor 614 determines whether the I2C/I3C master 651 has received an ACK response from the I2C/I3C slave 644 of the SerDes device 613 on the master side. If it is determined in step S352 that an ACK response has been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S353.
  • step S353 in the application processor 614, the I2C/I3C master 651 issues a register address (Register Address [15:8] shown in FIG. 42).
  • Register Address [15:8] shown in FIG. 42.
  • the payload below this register address is transmitted as shown in FIG.
  • step S354 the application processor 614 determines whether the I2C/I3C master 651 has received an ACK response from the I2C/I3C slave 644 of the SerDes device 613 on the master side. If it is determined in step S354 that an ACK response has been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S355.
  • step S355 in the application processor 614, the I2C/I3C master 651 determines whether the final data transfer has been completed. If it is determined in step S355 that the transfer of the final data has not been completed, the process returns to step S353, and the same process is repeated thereafter.
  • step S355 if it is determined in step S355 that the transfer of the final data has been completed, the process proceeds to step S356.
  • step S356 in the application processor 614, the I2C/I3C master 651 issues a stop command. As a result, the Sequence A_Write (during AP) processing ends, and the processing returns to step S322 in FIG.
  • step S352 or S354 determines whether an ACK response has been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side. If it is determined in step S352 or S354 that an ACK response has not been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S357.
  • step S357 in the application processor 614, the I2C/I3C master 651 issues a stop command. In this case, the Sequence A_Write (for AP) processing ends, and the communication processing itself ends.
  • FIG. 54 is a flowchart for explaining the Sequence A_Read_CMD (during AP) processing performed in step S331 of FIG.
  • the processing performed by the application processor 614 will be described as an example, but the Sequence A_Read_CMD (at SerDes (Slave)) processing in step S335 of FIG. 52 is performed in the same manner.
  • step S361 in the application processor 614, the I2C/I3C master 651 issues a start command and slave address (Slave Address+W8-bit shown in FIG. 42) to start the timer.
  • start command and slave address Slave Address+W8-bit shown in FIG. 42
  • step S362 the application processor 614 determines whether the I2C/I3C master 651 has received an ACK response from the I2C/I3C slave 644 of the SerDes device 613 on the master side. If it is determined in step S362 that an ACK response has been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S363.
  • step S363 in the application processor 614, the I2C/I3C master 651 issues a register address (Register Address [15:8] shown in FIG. 42).
  • Register Address [15:8] shown in FIG. 42.
  • step S364 the application processor 614 determines whether the I2C/I3C master 651 has received an ACK response from the I2C/I3C slave 644 of the SerDes device 613 on the master side.
  • step S364 If it is determined in step S364 that an ACK response has been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S365.
  • step S365 in the application processor 614, the I2C/I3C master 651 determines whether the final data transfer has been completed.
  • step S365 If it is determined in step S365 that the transfer of the final data has been completed, the process proceeds to step S366.
  • step S366 in the application processor 614, the I2C/I3C master 651 issues a stop command. Thereafter, the process branches into two, following branch A, the process proceeds to step S332 in FIG. On the other hand, according to branch B, after Sequence C (in AP) processing (see FIG. 55 described later) is performed in step S367, the processing proceeds to step S339 in FIG.
  • step S365 determines whether the transfer of the final data has been completed. If it is determined in step S365 that the transfer of the final data has not been completed, the process proceeds to step S368.
  • step S368 in the application processor 614, the I2C/I3C master 651 determines whether the timer started in step S361 has timed out. If it is determined in step S368 that the timer has not timed out, the process returns to step S363, and the same process is repeated thereafter.
  • step S368 determines whether the timer has timed out. If it is determined in step S368 that the timer has timed out, the process proceeds to step S369.
  • step S369 the application processor 614 sets the Error register (Timeout) to 1, and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers.
  • step S369 After the process of step S369, or if it is determined in step S362 or S364 that an ACK response has not been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S370.
  • step S370 in the application processor 614, the I2C/I3C master 651 issues a stop command.
  • the Sequence A_Read_CMD (during AP) process ends, and the communication process itself ends.
  • FIG. 55 is a flowchart explaining the Sequence C (during AP) processing performed in step S367 of FIG.
  • the processing performed by the application processor 614 will be described as an example, but the same processing can also be performed in the SerDes device 612 on the slave side.
  • step S381 in the application processor 614, the I2C/I3C master 651 determines whether or not the timer started in step S361 of FIG. If it is determined in step S381 that the timeout has occurred, the process proceeds to step S382, and in the application processor 614, the I2C/I3C master 651 performs a polling operation.
  • step S383 in the application processor 614, the I2C/I3C master 651 determines whether or not the Status register value of the read command is 1.
  • step S383 If it is determined in step S383 that the Status register value of the read command is 1, the process proceeds to step S384. In step S384, the application processor 614 performs read access, and then the process returns to step S339 in FIG.
  • step S383 determines whether the Status register value of the read command is 1 (other than 1), the process proceeds to step S385.
  • step S385 the application processor 614 sets the Error register (Timeout) to 1, and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers.
  • step S386 in the application processor 614, the I2C/I3C master 651 issues a stop command. In this case, the communication process itself is terminated as well as the Sequence C (during AP) process.
  • FIG. 56 is a flowchart for explaining the Sequence B (SerDes (Slave)) processing performed in steps S324 and S334 of FIG.
  • Sequence B SerDes (Slave)
  • FIG. 56 the processing performed by the SerDes device 612 on the slave side will be described as an example.
  • Processing and Sequence B (at SerDes (Master)) processing in step S332 of FIG. 52 are performed in the same manner.
  • step S391 in the slave-side SerDes device 612, the CCI-FS processing unit 636 confirms the Source ID of the slave-side SerDes device 612 and the DestinationSID of the extended packet header ePH.
  • step S392 in the slave-side SerDes device 612, the CCI-FS processing unit 636 determines whether the Source ID of the slave-side SerDes device 612 and the DestinationSID of the extended packet header ePH do not match.
  • step S392 If it is determined in step S392 that the Source ID of the SerDes device 612 on the slave side and the Destination SID of the extended packet header ePH do not match, the process proceeds to step S393.
  • step S393 in the slave-side SerDes device 612, the CCI-FS processing unit 636 confirms the Destination SID of the slave-side SerDes device 612 and the Destination SID of the extended packet header ePH.
  • step S394 in the slave-side SerDes device 612, the CCI-FS processing unit 636 determines whether the Source ID of the slave-side SerDes device 612 matches the DestinationSID of the extended packet header ePH.
  • step S394 If it is determined in step S394 that the Source ID of the SerDes device 612 on the slave side matches the Destination SID of the extended packet header ePH, the process proceeds to step S395.
  • step S395 in the SerDes device 612 on the slave side, the CCI-FS processing unit 636 confirms the Message Counter from the contents of the extended packet header ePH.
  • step S396 in the SerDes device 612 on the slave side, the CCI-FS processing unit 636 matches the Message Counter in the SerDes device 612 on the slave side with the received value of the Message Counter confirmed from the content of the extended packet header ePH. Determine whether or not
  • step S396 If it is determined in step S396 that the Message Counter in the SerDes device 612 on the slave side matches the received value of the Message Counter confirmed from the contents of the extended packet header ePH, the process proceeds to step S397.
  • step S397 in the slave-side SerDes device 612, the CCI-FS processing unit 636 converts the CRC calculation result calculated from the extension packet header ePH in the slave-side SerDes device 612 and the reception value (ePF0) of the extension packet footer ePF and
  • step S398 it is determined whether or not the received value (ePF0) of the extension packet footer ePF and the CRC calculation result match, and if it is determined that they match, the process returns to step S325 in FIG.
  • step S392 if it is determined in step S392 that the Source ID of the SerDes device 612 on the slave side and the Destination SID of the extended packet header ePH do not match (match), the process proceeds to step S399.
  • steps S399 to S402 the same processing as in steps S395 to S398 is performed.
  • step S402 If it is determined in step S402 that the received value (ePF0) of the extension packet footer ePF matches the CRC calculation result, the process proceeds to step S403. In step S403, write access is made to the register 637 of the SerDes device 612 on the slave side.
  • step S394 If it is determined in step S394 that the Source ID of the SerDes device 612 on the slave side and the Destination SID of the extended packet header ePH do not match, the process proceeds to step S404.
  • step S404 in the SerDes device 612 on the slave side, the CCI-FS processing unit 636 sets the Error register [2] (Routing) to 1, and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers. Store.
  • step S398 or S402 If it is determined in step S398 or S402 that the received value (ePF0) of the extension packet footer ePF and the CRC calculation result do not match, the process proceeds to step S405.
  • step S405 in the SerDes device 612 on the slave side, the CCI-FS processing unit 636 sets 1 in the Error register (CRC) and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers.
  • CRC Error register
  • step S396 or S400 If it is determined in step S396 or S400 that the Message Counter in the SerDes device 612 on the slave side does not match the received value of the Message Counter confirmed from the content of the extended packet header ePH, the process proceeds to step S406. .
  • step S406 in the SerDes device 612 on the slave side, the CCI-FS processing unit 636 sets 1 in the Error register (MC) and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers.
  • MC Error register
  • FIG. 57 is a flowchart for explaining the Sequence A_Read_Data (during AP) processing performed in step S339 of FIG.
  • the processing performed by the application processor 614 will be described as an example, but the Sequence A_Read_Data (when SerDes (Slave)) processing in step S336 of FIG. 52 is performed in the same manner.
  • step S411 in the application processor 614, the I2C/I3C master 651 issues a start command and a slave address (Slave Address+W8-bit shown in FIG. 48).
  • step S412 the application processor 614 determines whether the I2C/I3C master 651 has received an ACK response from the I2C/I3C slave 644 of the SerDes device 613 on the master side. If it is determined in step S412 that an ACK response has been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S413.
  • step S413 in the application processor 614, the I2C/I3C master 651 issues a start command and slave address (Slave Address+R8-bit shown in FIG. 48) to start the timer.
  • start command and slave address Slave Address+R8-bit shown in FIG. 48
  • step S414 the application processor 614 determines whether the I2C/I3C master 651 has received an ACK response from the I2C/I3C slave 644 of the SerDes device 613 on the master side. If it is determined in step S414 that an ACK response has been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S415.
  • step S415 in the application processor 614, the I2C/I3C master 651 acquires read data from the opposing I2C/I3C slave 644 on the application processor 614 side.
  • step S416 it is determined whether or not the I2C/I3C master 651 of the application processor 614 has transmitted an ACK, and the I2C/I3C slave 644 opposite to the application processor 614 has received an ACK.
  • step S416 If it is determined in step S416 that the I2C/I3C master 651 of the application processor 614 has transmitted an ACK and that the I2C/I3C slave 644 on the side of the application processor 614 has received an ACK, the process proceeds to step S417. move on.
  • step S417 it is determined whether or not the I2C/I3C master 651 of the application processor 614 has transmitted a NACK following the completion of the final data transfer.
  • step S417 If it is determined in step S417 that NACK transmission has been performed, the process proceeds to step S418.
  • step S4108 in the application processor 614, the I2C/I3C master 651 issues a stop command. This completes the Sequence A_Read_Data (during AP) process, and the process returns to step S340 in FIG.
  • step S417 determines whether NACK transmission has been performed. If it is determined in step S417 that NACK transmission has not been performed, the process proceeds to step S419.
  • step S419 in the application processor 614, the I2C/I3C master 651 determines whether the timer started in step S413 has timed out. If it is determined in step S419 that the timer has not timed out, the process returns to step S415, and the same process is repeated thereafter.
  • step S419 determines whether the timer has timed out. If it is determined in step S419 that the timer has timed out, the process proceeds to step S420.
  • step S420 the application processor 614 sets the Error register (Timeout) to 1, and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers.
  • step S420 After the process of step S420, or if it is determined in step S414 that an ACK response has not been received from the I2C/I3C slave 644 of the SerDes device 613 on the master side, the process proceeds to step S421. Similarly, in step S416, it was determined that the I2C/I3C master 651 of the application processor 614 did not transmit ACK, or that the opposite I2C/I3C slave 644 on the application processor 614 side did not receive ACK. If so, the process proceeds to step S421.
  • step S421 in the application processor 614, the I2C/I3C master 651 issues a stop command.
  • the Sequence A_Read_Data (during AP) processing ends, and the communication processing itself ends.
  • the access timing from the I2C/I3C master 634 to the I2C/I3C slave 621 and the I2C/I3C slave 644 of the SerDes device 613 on the master side are There are three combinations of access timing from the I2C/I3C master 651 to the I2C/I3C slave 644 when outputting (see FIG. 48).
  • the first access timing is polling until the read data is acquired, and the I2C/I3C master starts read processing after the read data read preparation is completed.
  • the I2C/I3C master starts read processing after a certain period of time has passed.
  • the third access timing uses the Clock Stretch method (see FIG. 72, which will be described later), and the I2C/I3C master starts read processing after a certain period of time has passed. There is also a form in which data is sent in pieces (asserting the Clock Stretch Mode signal).
  • ⁇ Configuration example of extended packet header ePH> 58 to 60 are diagrams showing configuration examples of the extension packet header ePH.
  • FIG. 58 shows a detailed configuration example of the extended packet header ePH0, extended packet header ePH1, and extended packet header ePH2.
  • the content of the extended packet header ePH is specified for CCI-FS by diverting the ePH structure in C-PHY and D-PHY.
  • FIG. 59 shows a detailed configuration example of the extended packet header ePH3.
  • the contents of the extended packet header ePH are defined for CCI-FS.
  • FIG. 60 shows a detailed configuration example of the extended DT of the extended packet header ePH.
  • "0xC0: For I2C” and "0xC1: For I3C” are added to the data type of the extended packet header ePH to support CCI-FS.
  • FIG. 61 shows a configuration example of conventional I2C hardware.
  • an I2C configuration example in the case of a bus connection configuration is shown at the time of hardware implementation, and the slave side may be configured to receive AKC/NACK from the host.
  • the upper bus configurations do not necessarily match.
  • FIG. 62 shows waveforms during data transfer on the I2C bus. Note that the I2C bus standard and CCI (I2C) are equivalent.
  • FIG. 63 is a block diagram showing a CCI-related configuration example in a communication system 701 having an A-PHY direct connection configuration, like the communication system 501 shown in FIG. 27 above.
  • an image sensor 711 and an application processor 712 are directly connected by A-PHY.
  • the image sensor 711 includes an A-PHY processing unit 721, a CSIA processing unit 722, a CSI2 processing unit 523, a CSI2-FS processing unit 724, a CCI processing unit 725, a CCI-FS processing unit 726, a register 727, and a selector 728-1. and 728-2.
  • selectors 728-1 and 728-2 are arranged to sandwich the CCI-FS processing unit 726, and enable/disable the CCI-FS processing unit 726 according to the CCI_FS_Enable signal of the register 727. can be done.
  • the application processor 712 includes an A-PHY processing unit 731, a CSIA processing unit 732, a CSI2 processing unit 733, a CSI2-FS processing unit 734, a CCI processing unit 735, a CCI-FS processing unit 736, a register 737, and a selector 738-1. and 738-2. As shown, the selectors 738-1 and 738-2 are arranged to sandwich the CCI-FS processing unit 736, and switch enable/disable of the CCI-FS processing unit 736 according to the CCI_FS_Enable signal of the register 737. can be done.
  • data is transmitted through the CCI-FS processing unit 726 and the CCI-FS processing unit 736 as indicated by the dashed-dotted arrows. are sent and received.
  • the CCI-FS processing unit 726 and CCI-FS processing unit 736 are data is sent to and received from
  • FIG. 64 shows an example of network connection form (topology) of A-PHY direct connection configuration and SerDes connection configuration.
  • the application processor 801 is directly connected to the image sensor 802 via A-PHY, and the image sensor 802 can configure a connection form that is connected to the sensor 803 via I2C/I3C.
  • the application processor 801 is connected to the master-side SerDes device 804 via I2C/I3C, and the master-side SerDes device 804 and the slave-side SerDes device 805 are connected via A-PHY.
  • the SerDes device 805 on the slave side can configure a topology that connects to two sensors 806-1 and 806-2 via I2C/I3C.
  • FIG. 65 is a block diagram showing an example of the circuit configuration of the CCI-FS processing section.
  • a CCIFS processing unit 901 and a register 902 shown in FIG. 65 have a common configuration for the CCI-FS processing units and registers included in each device described above.
  • the CCI-FS processing unit 901 has a CCI-FS switch, a register, etc. in the upper layer, and a CCI processing unit in the lower layer.
  • the CCI-FS processing section 901 is configured with a CCI-FS transmitting section 911 and a CCI-FS receiving section 912 .
  • Various register set value information is supplied from the register 902 to the CCI-FS processing unit 901 , and an error notification is supplied from the CCI-FS processing unit 901 to the register 902 .
  • the CCI-FS transmission unit 911 comprises an extended packet header ePH generation unit 921, an extended packet footer ePF generation unit 922, and a Destination Address confirmation unit 923.
  • the extended packet header ePH generation unit 921 has an MC generation unit 941 that generates a Message Counter and a Packet Length calculation unit 942 that calculates the packet length.
  • the extended packet footer ePF generator 922 has an extended packet footer ePF1 generator 943 that generates the extended packet footer ePF1 and a CRC calculator 944 that calculates the CRC stored in the extended packet footer ePF0.
  • the CCI-FS receiving unit 912 comprises an extended packet header ePH confirming unit 931, an extended packet footer ePF confirming unit 932, and a Destination Address confirming unit 933.
  • the extended packet header ePH confirmation unit 931 has an MC confirmation unit 951 that confirms the Message Counter, and a Packet Length calculation/confirmation unit 952 that calculates and confirms the packet length.
  • the extended packet footer ePF checking unit 932 has an extended packet footer ePF1 checking unit 953 that checks the extended packet footer ePF1, and a CRC calculator 954 that calculates the CRC stored in the extended packet footer ePF0.
  • the CCI-FS processing unit 901 uses the CCI-FS transmission unit 911 to confirm the Destination Address of the data from the upper layer, generate the extended packet header ePH and the extended packet footer ePF, add them to the data, and can be supplied to
  • the CCI-FS processing unit 901 can confirm the Destination Address of the data from the lower layer by the CCI-FS receiving unit 912, confirm the extended packet header ePH and the extended packet footer ePF, and supply them to the upper layer. can.
  • the application processor 614 has a Source ID indicating its own device in the extended packet header ePH of the application processor 614. Then, the CCI-FS processing unit 653 adds the above information and information having a Destination ID indicating a device to be accessed.
  • the SerDes device 612 on the slave side and the SerDes device 613 on the master side have Source IDs indicating their own devices, either by presetting them or as unique values.
  • the CCI-FS processing unit 636 and the CCI-FS processing unit 646 preset the above information and information having a Destination ID indicating the connected device and the target device.
  • the CCI-FS processing unit 636 and the CCI-FS processing unit 646 compare the Destination ID of the received extension packet header ePH with its own ID (Source ID), and indicate access to itself or the target device. (Destination ID). For example, when the Destination ID of the received extension packet header ePH matches its own ID (Source ID), it accesses its own register as an access to the intermediate device (SerDes device). On the other hand, if the Destination ID of the received extension packet header ePH does not match its own ID (Source ID), data is transferred to the connected device (Destination ID) as an access to the subsequent device.
  • data is sent based on the Source ID and Destination ID embedded in the extended packet header ePH, the preset or unique value SourceID, and the preset connection destination information to the intermediate device (SerDes device) or target device. and access to the target device.
  • the CSI2-FS processing unit 623 of the image sensor 611 accesses its own register as access to the image sensor 611 when the Destination ID of the received extension packet header ePH matches its own ID (Source ID). conduct.
  • the Source ID that each device has can use a unique value for each device, a preset value, or a combination thereof.
  • FIG. 66 to 68 are diagrams showing detailed configuration examples of the register 902.
  • FIG. 66 to 68 are diagrams showing detailed configuration examples of the register 902.
  • FIG. 66 shows the details of register 902 from address 0x000 to address 0x109.
  • FIG. 67 shows a configuration example in the case of Bridge configuration as details from address 0x110 to address 0x125 of the register 902 .
  • FIG. 68 shows Error-related registers as details of address 0x200 of register 902 .
  • FIG. 68 shows Error-related registers (debug) as details of addresses 0x300 and 0x400 of register 902 .
  • FIG. 68 shows the Error Injection related register (debug) as details of address 0x800 of register 902 .
  • FIG. 69 shows a modification of the extended packet header ePH in the packet configuration of the write data generated by the CCI-FS processing unit 536 of the application processor 512 during write access, as described above with reference to FIG. It is shown.
  • the extension packet header ePH shown in FIG. 69 differs from the configuration example shown in FIG. 33 described above in the configuration of extension packet header ePH3 and extension packet header ePH4.
  • FIG. 70 shows a modification of the extended packet header ePH in the packet configuration of the write data generated in the CCI-FS processing unit 536 of the application processor 512 during read access, as described above with reference to FIG. It is shown.
  • the extension packet header ePH shown in FIG. 70 differs from the configuration example shown in FIG. 28 in the configurations of extension packet header ePH3 and extension packet header ePH4.
  • Read address information may be stored in the extended packet header ePH or in the AP (CCI) payload.
  • the Length information may be stored in the extended packet header ePH or may be stored in the AP (CCI) payload.
  • CMD information may be stored in the CCI Command ID of the extended packet header ePH. Based on the CCI Command ID, the start, resume, and end information of the command are referenced.
  • CCI Header Length may be used to store CCI information (for example, Slave Address, etc.) in the AP (CCI) payload.
  • CCI Header Length is information indicating the header length of the CCI protocol (I2C).
  • FIG. 71 is a diagram explaining the flow between the image sensor 511 and the application processor 512 in the A-PHY direct connection configuration as shown in FIG.
  • the CCI-FS switch 538 issues read commands and write commands.
  • the CCI processing unit 535 converts them into AP (CCI) payloads and supplies them to the A-PHY processing unit 531 .
  • the A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to the AP (CCI) payload, and performs A-PHY transfer to the image sensor 511 .
  • the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer and supplies the AP (CCI) payload to the CCI processing unit 525 .
  • the CCI processing unit 525 converts the AP (CCI) payload, writes data to the register 527 according to the write command, and reads data from the register 527 according to the read command, based on the contents thereof.
  • initial setting of CCI-FS Enable is performed by the CCI processing unit 525, and bus conversion such as register interface and AHB bus is performed. Confirmation of the CCI-FS Enable setting is performed via the CCI processing unit 525 or the CCI-FS processing unit 526 .
  • the A-PHY processing unit 521 adds an A-PHY header and an A-PHY footer to the AP (CCI) payload, and performs A-PHY transfer to the application processor 512 .
  • the A-PHY processing unit 531 removes the A-PHY header and APHY footer and supplies the AP (CCI) payload to the CCI processing unit 535 .
  • the CCI-FS switch 538 performs CCI-FS Enable setting and various CCI-FS related register settings for the register 537 . At this time, the register access depends on the implementation.
  • the CCI-FS switch 538 sends a CCI-FS related Set various registers.
  • the CCI-FS switch 538 issues a read command.
  • the A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to them and performs A-PHY transfer to the image sensor 511 .
  • the CCI-FS processing unit 526 converts the AP (CCI) payload, and reads data from the register 527 according to the read command based on the contents thereof.
  • register access depends on the implementation, and bus conversion such as register interface, AHB bus, and CCI interface is performed.
  • the A-PHY processing unit 521 adds an A-PHY header and an A-PHY footer to them, and performs A-PHY transfer to the application processor 512 .
  • the footer ePF0 is supplied to the CCI-FS processing unit 536.
  • I2C/I3C generation by software Slave Address, Register address, Payload, ACK response reception, transmission, various control codes (S, Sr, ACK, NACK, P) are generated by software (for example, GPIO control image).
  • I2C/I3C command generation by software CPU issues Slave Address, Register address, Payload in response to ACK reception by CPU bus setting.
  • transfer settings and data are set in the I2C/I3C HW IP as I2C/I3C generation in hardware.
  • Various control codes are automatically responded by hardware.
  • As an I2C/I3C command generation in hardware set data in the transfer setting to HW IP of I2C/I3C and send it by command.
  • Various control codes are automatically responded by hardware.
  • FIG. 72 is a diagram explaining the flow using the Clock Stretch method in Write access and Read access between the image sensor 611 and the application processor 614 in the SerDes connection configuration as shown in FIG.
  • the CCI-FS switch 655 of the application processor 614 supplies the start command and write command (Slave Address+W 8bit) to the CCI processing unit 645 of the master-side SerDes device 613 and asserts the Scl_enb signal.
  • the CCI processing unit 645 supplies the write command to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds the A-PHY header and A-PHY footer to the write command. , A-PHY transfer to the SerDes device 612 on the slave side.
  • the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the write command to the CCI processing unit 635 (Slave).
  • the CCI processing unit 635 (Slave) negates the Scl_enb signal and supplies a write command to the CCI processing unit 635 (Master).
  • the CCI processing unit 635 that communicates with the SerDes device 613 on the master side and functions as a slave is called a CCI processing unit 635 (Slave), and the CCI processing that communicates with the image sensor 611 side and functions as a master.
  • the unit 635 is called a CCI processing unit 635 (master).
  • the CCI processing unit 635 (Master) transmits a start command and a write command to the image sensor 611.
  • the CCI processing unit 622 receives the start command and the write command and supplies them to the CSI2-FS processing unit 623.
  • the CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the SerDes device 612 on the slave side.
  • the CCI processing unit 635 (Master) receives the ACK response and the Scl_enb signal is negated from the CCI processing unit 635 (Slave), the ACK response is supplied to the CCI-FS processing unit 636. . After that, the CCI processing unit 635 (Slave) asserts the Scl_enb signal to the CCI processing unit 635 (Master).
  • the CCI-FS processing unit 636 supplies the ACK response to the A-PHY processing unit 631.
  • the A-PHY processing unit 631 adds an A-PHY header and an A-PHY footer to the ACK response, and performs A-PHY transfer to the SerDes device 613 on the master side.
  • the A-PHY processing unit 641 removes the A-PHY header and A-PHY footer and supplies the ACK response to the CCI processing unit 645 .
  • the CCI-FS switch 655 of the application processor 614 negates the Scl_enb signal to the CCI processing unit 645
  • the CCI processing unit 645 transmits an ACK response to the application processor 614 .
  • the CCI processing unit 652 receives the ACK response and supplies it to the CCI-FS switch 655 via the CCI-FS processing unit 653.
  • the CCI-FS switch 655 of the application processor 614 supplies the register address (Register Address[7:0]) to the CCI processing unit 645 of the SerDes device 613 on the master side, and asserts the Scl_enb signal.
  • the CCI processing unit 645 supplies the register address to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds the A-PHY header and A-PHY footer to the register address. , A-PHY transfer to the SerDes device 612 on the slave side.
  • the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the register address to the CCI processing unit 635 (Slave).
  • the CCI processing unit 635 (Slave) negates the Scl_enb signal and supplies the register address to the CCI processing unit 635 (Master).
  • the CCI processor 635 (Master) transmits the register address to the image sensor 611 . After that, the CCI processing unit 635 (Slave) asserts the Scl_enb signal to the CCI processing unit 635 (Master).
  • the CCI processing unit 622 receives the register address and supplies it to the CSI2-FS processing unit 623.
  • the CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the SerDes device 612 on the slave side.
  • the CCI processing unit 635 (Slave) asserts the Scl_enb signal to the CCI processing unit 635 (Master).
  • the CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the SerDes device 612 on the slave side.
  • the CCI-FS switch 655 of the application processor 614 supplies the write data (Dara0[7:0]) to the CCI processing unit 645 of the SerDes device 613 on the master side and asserts the Scl_enb signal.
  • the CCI processing unit 645 supplies the write data to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the write data. , A-PHY transfer to the SerDes device 612 on the slave side.
  • the CCI processing unit 645 receives the write data, and supplies the write data to the A-PHY processing unit 641 when the Scl_enb signal is asserted from the CCI-FS switch 655 .
  • the CSI2-FS processing unit 653 negates the Scl_enb signal to the CCI processing unit 645 under the control of the CCI-FS switch 655 .
  • the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the write data, and performs A-PHY transfer to the SerDes device 612 on the slave side.
  • the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the write data to the CCI processing unit 635 .
  • the CCI processing unit 635 negates the Scl_enb signal and supplies write data to the CCI processing unit 635 (master).
  • the CCI processing unit 635 (master) transmits write data to the image sensor 611 .
  • the CCI processing unit 635 (Slave) asserts the Scl_enb signal to the CCI processing unit 635 (Master).
  • the CCI processing unit 622 receives the write data and supplies it to the CSI2-FS processing unit 623, and the CSI2-FS processing unit 623 writes the write data to the register 624.
  • the CSI2-FS processing unit 623 supplies an ACK response indicating that the write data has been successfully written to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the SerDes device 612 on the slave side.
  • the CCI-FS processing unit 653 transmits the extended packet footer ePF0 to the SerDes device 613 on the master side under the control of the CCI-FS switch 655.
  • the CCI processing unit 645 receives the extension packet footer ePF0, and when the Scl_enb signal is asserted from the CCI-FS switch 655, supplies the extension packet footer ePF0 to the A-PHY processing unit 641. . After that, the CCI-FS switch 655 negates the Scl_enb signal to the CCI processor 645 .
  • the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the extension packet footer ePF0, and performs A-PHY transfer to the SerDes device 612 on the slave side.
  • the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the extension packet footer ePF0 to the CCI-FS processing unit 636.
  • the CCI-FS processing unit 636 negates the Scl_enb signal and supplies the extended packet footer ePF0 to the CCI processing unit 635 (Master).
  • the CCI processing unit 635 (master) transmits the extended packet footer ePF0 to the image sensor 611 .
  • the CCI processing unit 635 (Slave) asserts the Scl_enb signal to the CCI processing unit 635 (Master).
  • the CSI2-FS processing unit 623 receives the extended packet footer ePF0.
  • the CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the SerDes device 612 on the slave side.
  • the CCI-FS switch 655 of the application processor 614 supplies the repeat start command and read command (Slave Address+R 8bit) to the CCI processing unit 645 of the SerDes device 613 on the master side, and asserts the Scl_enb signal.
  • the CCI processing unit 645 supplies the read command to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds the A-PHY header and A-PHY footer to the read command. , A-PHY transfer to the SerDes device 612 on the slave side.
  • the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the read command to the CCI processing unit 635 (Slave).
  • the CCI processing unit 635 (Slave) negates the Scl_enb signal and supplies a read command to the CCI processing unit 635 (Master).
  • the CCI processing unit 635 (master) transmits the repeat start command and read command to the image sensor 611 .
  • the CCI processing unit 622 receives the repeat start command and read command and accesses the register 624.
  • the CCI processing unit 622 transmits an ACK response indicating successful reception to the SerDes device 612 on the slave side.
  • the CCI processing unit 622 reads the read data (Data0[7:0]) from the register 624 and transmits it to the SerDes device 612 on the slave side.
  • the CCI processing unit 635 (Master) receives the read data and supplies it to the CCI processing unit 635 (Slave), and the CCI processing unit 635 (Slave) performs A-PHY processing on the read data. 631.
  • the A-PHY processing unit 631 adds an A-PHY header and an A-PHY footer to the read data, and performs A-PHY transfer to the SerDes device 613 on the master side.
  • the A-PHY processing unit 641 removes the A-PHY header and A-PHY footer and supplies the read data to the CCI processing unit 645 , and the CCI processing unit 645 sends the read data to the application processor 614 . Send read data.
  • the CCI processing unit 652 receives the read data and supplies it to the CCI-FS switch 655 via the CCI-FS processing unit 653.
  • the CCI-FS switch 655 transmits a NACK response and a stop command to the CCI processing section 645.
  • the CCI processing section 645 supplies the NACK response and the stop command to the A-PHY processing section 641 .
  • the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the NACK response and stop command, and performs A-PHY transfer to the SerDes device 612 on the slave side.
  • the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the NACK response and stop command to the CCI processing unit 635 (Slave).
  • the CCI processing unit 635 (Slave) supplies the NACK response and the stop command to the CCI processing unit 635 (Master), and the CCI processing unit 635 (Master) transmits the NACK response and the stop command to the image sensor 611 .
  • the CCI processing unit 622 receives the NACK response and the stop command and supplies them to the CSI2-FS processing unit 623.
  • I2C control commands such as start, repeat start, ACK response, NACK response, and stop are assigned to a 1-byte Payload by setting the Control Code Indicator of the extended packet header ePH0 to 1. shows each code.
  • FIG. 73 is a block diagram showing a configuration example of the configuration in which the image sensor 211 shown in FIG. In the image sensor 211 shown in FIG. 73, the same components as those of the image sensor 211 shown in FIG.
  • CCI-FS processing unit 1001 is arranged between CCI slave 224 and register 47, and MUX units 1002-1 and 1002-2 are arranged so as to sandwich CCI-FS processing unit 1001.
  • MUX units 1002-1 and 1002-2 transmit and receive data via CCI-FS processing unit 1001 when CCI-FS processing unit 1001 is enabled according to the cci_fs_en signal supplied from register 47.
  • MUX units 1002-1 and 1002-2 transmit and receive data without going through CCI-FS processing unit 1001 when CCI-FS processing unit 1001 is disabled according to the cci_fs_en signal supplied from register 47. do.
  • FIG. 74 is a block diagram showing a configuration example in which the application processor 214 shown in FIG. In the application processor 214 shown in FIG. 74, components common to those of the application processor 214 shown in FIG.
  • CCI-FS processing unit 1101 is arranged between CCI master 254 and register 73, and MUX units 1102-1 and 1102-2 are arranged so as to sandwich CCI-FS processing unit 1101. .
  • the MUX units 1102-1 and 1102-2 transmit and receive data via the CCI-FS processing unit 1101 according to the cci_fs_en signal supplied from the register 73 when the CCI-FS processing unit 1101 is enabled.
  • the MUX units 1102-1 and 1102-2 transmit and receive data without going through the CCI-FS processing unit 1101 when disabling the CCI-FS processing unit 1101 according to the cci_fs_en signal supplied from the register 73. do.
  • the following configuration may be adopted for the method of implementing each field in the configuration of the extended packet header ePH.
  • the extended VC shall not be used in Safe CCI. (The same structure is used to match the header field with the extension header related in MIPI)
  • ⁇ In the extension DT it may be embedded in the command related information of the bus from the upper level, or the signal line setting from the register setting is implemented. may be configured. ⁇ The protocol is described in I2C, but the same can be done in I3C SDR mode.
  • FIG. 75 A fourth embodiment of a communication system to which the present technology is applied will be described with reference to FIGS. 75 to 117.
  • FIG. 75 A fourth embodiment of a communication system to which the present technology is applied will be described with reference to FIGS. 75 to 117.
  • FIG. 75 is a block diagram of a communication system according to the fourth embodiment.
  • FIG. 75A shows a communication system 1201 as a first variation
  • FIG. 75B shows a communication system 1201A as a second variation.
  • a communication system 1201 shown in A of FIG. 75 is configured by directly connecting an image sensor 1211 and an application processor 1212 .
  • the ALL layer 1222 is arranged on the A-PHY layer 1221, and the CSI-2 transmission section 1223 and the CSI extension section 1224, and the CCI slave 1225 and the CCI extension section 1226 are arranged thereon. It is configured.
  • the image sensor 1211 can support extended standards by providing a CSI extension unit 1224 for the CSI-2 transmission unit 1223 and a CCI extension unit 1226 for the CCI slave 1225. becomes.
  • the application processor 1212 has an ALL layer 1232 placed above the A-PHY layer 1231, above which are placed a CSI-2 receiver 1233 and a CSI extension 1234, and a CCI master 1235 and a CCI extension 1236. It is configured.
  • the application processor 1212 can support extended standards by providing a CSI extension unit 1234 for the CSI-2 reception unit 1233 and a CCI extension unit 1236 for the CCI master 1235. becomes.
  • CSI extensions may also be referred to as Camera Service Extensions (CSE).
  • a communication system 1201A shown in FIG. 75B is configured by connecting a display 1213 and an application processor 1212A.
  • the application processor 1212A is configured with a DSI-2 transmission unit 1233A and a DSI extension unit 1234A instead of the CSI-2 reception unit 1233 and the CSI extension unit 1234 of the application processor 1212 of A of FIG.
  • Other blocks have a common configuration with the application processor 1212 .
  • a display 1213 has an ALL layer 1242 arranged on an A-PHY layer 1241, and a DSI-2 receiving section 1243 and a DSI extension section 1244 as well as a CCI slave 1245 and a CCI extension section 1246 arranged thereon. It has become.
  • the display 1213 can correspond to the extended standards by providing a DSI extension section 1244 for the DSI-2 reception section 1243 and a CCI extension section 1246 for the CCI slave 1245. Become.
  • DSI extensions may also be referred to as Display Service Extensions (DSE).
  • the communication systems 1201 and 1201A configured in this way perform high-speed data transmission for transmitting data of frames including image data in one direction, and low-speed command transmission for transmitting commands related to high-speed data transmission in the opposite direction (however, Transmission of the command itself may be referred to as command transmission, and transmission of a response to the command may be referred to as command transmission).
  • Transmission of the command itself may be referred to as command transmission
  • transmission of a response to the command may be referred to as command transmission
  • high-speed data transmission start instruction requesting the start of high-speed data transmission is transmitted, but this need not be the case.
  • high-speed data transmission is faster than low-speed command transmission, and is started in response to the reception of a high-speed data transmission start command, but this need not be the case.
  • the communication system 1201 in which the communication partner of the application processor 1212 is the image sensor 1211 and the communication system 1201A in which the communication partner of the application processor 1212A is the display 1213 differ in the direction of high-speed data transmission and low-speed command transmission. That is, image data is transmitted from the image sensor 1211 to the application processor 1212 in the communication system 1201, and image data is transmitted from the application processor 1212A to the display 1213 in the communication system 1201A.
  • A-PHY In the physical layer standard A-PHY, high-speed data transmission and low-speed command transmission are transmitted partially or entirely through a common communication path.
  • A-PHY also enables part or all of the power supply from the application processor 1212 to the image sensor 1211 and the power supply from the application processor 1212A to the display 1213 to be transmitted via a common communication path. Support options.
  • low-speed command transmission conforms to CCI of the CSI-2 standard, for example, and communication is performed based on the I2C or I3C standard.
  • the low-speed command transmission uses not only the independent physical layer of I2C or I3C, but also part or all of the physical layer of D-PHY, C-PHY, and A-PHY to transmit the command.
  • high-speed data transmission transmits data through some or all of the physical layers of D-PHY, C-PHY, and A-PHY.
  • commands are transmitted through part or all of the physical layer of either D-PHY or C-PHY. It is possible to That is, high-speed data transmission and low-speed command transmission can be transmitted partially or wholly through any one of D-PHY, C-PHY, A-PHY, I2C, and I3C physical layers.
  • USB Unified Serial Link
  • FIG. 75 a configuration example including application processors 1212 and 1201A has been described, but the communication systems 1201 and 1201A may be configured including an electronic control unit (ECU), for example.
  • the processor is not limited to the application processor 1212 as long as it can communicate with the image sensor 1211, the display 1213, or the like through direct connection or indirect connection.
  • a configuration including various sensors other than the image sensor 1211 may be employed.
  • Communication systems 1201 and 1201A configured in this manner employ a method of transmitting nonce values or an initialization vector configuration including nonce values as described below.
  • certain symmetric-key cryptographic algorithms eg, AES-GCM/GMAC
  • AES-GCM/GMAC symmetric-key cryptographic algorithms
  • the rules for setting initialization vectors and nonce values are agreed in advance between the image sensor 1211 and the application processor 1212 or between the display 1213 and the application processor 1212A.
  • the present technology provides a method of transmitting a nonce value or an initialization vector configuration including a nonce value suitable for an imaging device that conforms to the CSI standard, including the image sensor 1211, or a display device that conforms to the DSI standard, including the display 1213. disclose.
  • FIG. 76 is a block diagram showing a detailed configuration example of the image sensor 1211. As shown in FIG.
  • the image sensor 1211 includes pixels 1301, an AD converter 1302, an image processing unit 1303, an extension mode compatible CSI-2 transmission circuit 1304, a physical layer processing unit 1305, an I2C/I3C slave 1306, a storage unit 1307, a message counter 1308, and a nonce update. It is composed of a unit 1309 and a security unit 1310 . Note that the pixel 1301, AD converter 1302, image processing unit 1303, extended mode compatible CSI-2 transmission circuit 1304, physical layer processing unit 1305, I2C/I3C slave 1306, and storage unit 1307 are similar to those of the other embodiments described above. are configured in the same manner as corresponding blocks in , and detailed description thereof will be omitted.
  • the message counter 1308 updates the message count value within the image sensor 1211 each time an extension packet that satisfies a predetermined count condition is transmitted.
  • the security unit 1310 derives a session key in the image sensor 1211 and provides first protection data (e.g., integrity computation value computed to protect integrity, confidentiality protection) of data transmitted at high speed data. (encrypted data for the session) is generated using the session key.
  • first protection data e.g., integrity computation value computed to protect integrity, confidentiality protection
  • the nonce update unit 1309 updates the nonce (number used once) value in the image sensor 1211 each time the security unit 1310 generates the first protection data.
  • the image sensor 1211 configured in this manner performs high-speed data transmission of part or all of the nonce value and part or all of the message count value to the application processor 1212 .
  • some or all of the nonce values may be count values or random numbers.
  • Part or all of the nonce value is stored outside the extension packet header and transmitted, and the image data is stored and transmitted within the packet data.
  • the message counter 1308 and the nonce updater 1309 may be configured separately or integrally.
  • updating of the nonce value and message count value can be asynchronous. This allows greater flexibility in the nonce value and message count value.
  • the message counter 1308 and the nonce updater 1309 are integrated, updating of the nonce value and the message count value can be synchronized.
  • the bit width of the message counter 1308 can be saved by sharing the message count value with part or all of the nonce value. That is, the message counter 1308 may be part or all of the nonce update unit 1309, and part or all of the nonce update unit 1309 may be shared.
  • FIG. 77 is a block diagram showing a detailed configuration example of the application processor 1212. As shown in FIG.
  • the application processor 1212 comprises a physical layer processing unit 1321, an extended mode compatible CSI-2 receiving circuit 1322, an I2C/I3C master 1323, a storage unit 1324, a data verification unit 1325, a security unit 1326, and a controller 1327.
  • the physical layer processing unit 1321, the extended mode compatible CSI-2 receiving circuit 1322, the I2C/I3C master 1323, and the storage unit 1324 are configured in the same manner as the corresponding blocks in the other embodiments described above. detailed description is omitted.
  • the data verification unit 1325 verifies the validity of the nonce value or message count value transmitted from the image sensor 1211 to the application processor 1212 .
  • the security unit 1326 derives a session key within the application processor 1212 corresponding to the session key within the image sensor 1211, and uses the session key within the application processor 1212 to verify the first protected data of the image data (integrity verification). ) or decrypt.
  • the data verification unit 1325 can verify the continuity when the data to be verified is a count value. Further, the data verification unit 1325 may be configured to include a counter, and comparison verification may be performed by updating the count value in the same manner as the image sensor 1211 . In addition, when the data to be verified is a random number, the data verification unit 1325 may verify its randomness. Note that the data verification unit 1325 includes a nonce update unit 1309 (or a message counter), which may be used to verify or decrypt the first protected data, and may be used to verify data to be verified. .
  • the image sensor 1211 and application processor 1212 can be configured to be mounted on a desired mobile device.
  • the mobile device may be a portable mobile device, such as a mobile phone, smart phone, digital camera, game device, or the like.
  • the mobile device may be a propulsion device, and may be, for example, a vehicle, robot, drone, or the like capable of propulsion (any of movable, running, walking, flying, etc.).
  • the mobile device may be an autonomous vehicle, an autonomous robot, an autonomous drone, or the like, which is equipped with an AI (Artificial Intelligence) function and capable of autonomous propulsion.
  • the propulsion of the propulsion device may be controlled by the user of the propulsion device, and the propulsion device may provide instructions or warnings to the user as necessary.
  • the propulsion device may be configured such that the propulsion device automatically controls the propulsion of the propulsion device.
  • the security units 1310 and 1326 may each include, for example, a security calculation unit that performs calculations for protecting image data. Therefore, the security units 1310 and 1326 perform encryption operation, decryption operation, hash value operation, message authentication code operation, digital signature operation, ID (identification) authentication, firmware measurement, encryption session key establishment, and so on. , key exchange, key update, etc.
  • any one of the security units 1310 and 1326, the nonce update unit 1309, the message counter 1308, and the data verification unit 1325 can be configured to be electrically directly connected to the memory.
  • This memory may be electrically connected directly to the register, and any one of security units 1310 and 1326, nonce update unit 1309, message counter 1308, and data verification unit 1325 is electrically connected directly to the register.
  • the memory may be memory that is protected from either disclosure or tampering with information in memory. Such memories and registers are used as storage units 1307 and 1324, respectively.
  • Storage units 1307 and 1324 store key information (for example, pre-shared key, secret key, public key, or session key), certificates (for example, root certificate, intermediate certificate, or leaf certificate), encryption algorithm Any such information may be stored.
  • Storage units 1307 and 1324 store function information of the image sensor 1211 or application processor 1212, ID information of the image sensor 1211 or application processor 1212 (for example, source ID, destination ID, final destination ID, etc.), image sensor 1211 or application processor 1212 firmware information may be stored.
  • Storage units 1307 and 1324 store session information (for example, session ID), calculation values of the security calculation unit (for example, initial value, intermediate value, or final value), initialization vector, nonce value, and message count value, which will be described later. , frame number (frame count value), or the like may be stored.
  • any one of the security units 1310 and 1326, the nonce update unit 1309, the message counter 1308, and the data verification unit 1325 for example, the image sensor 1211 or the application processor 1212 can generate multiple nonce values, count values, and integrity calculation values. , encrypted information, etc., in the storage unit 1307 or 1324, it becomes possible to determine the presence or absence of a problem, and to take appropriate measures (for example, a request to resend data at the problem location, an abnormal message, etc.). transmission) is also possible. Also, if any of the nonce value, the count value, the integrity calculation value, the encrypted information, etc. is periodically saved in the protected storage unit 1307 or 1324, even if an accident of the mobile device occurs, In addition, the analysis of the protected storage unit 1307 or 1324 has the effect of facilitating identification of the cause of the accident.
  • Requesters and responders ie application processor 1212 and image sensor 1211, can have one or more communication channels depending on the session.
  • a session will be described below using an example configuration in which the application processor 1212 is the requester and the image sensor 1211 is the responder.
  • application processor 1212 may be the responder and image sensor 1211 may be the requester.
  • a session provides either encryption or message authentication, or both.
  • a session includes, for example, three phases: a session handshake phase, an application phase, and a session termination phase.
  • the session handshake stage starts with a key exchange request (either PSK_EXCHANGE or KEY_EXCHANGE) from the requester, derives a session key such as a session secret or an encryption key, and uses the session key to protect communications.
  • the purpose of this stage may be to first build trust between the responder and the requestor before either side sends application data (eg, image data). Additionally, some degree of handshake integrity and synchronicity with the derived handshake secret may be guaranteed.
  • the session may end immediately and proceed to session termination.
  • a successful handshake is terminated, for example, by a finish response (FINISH_RSP or PSK_FINISH_RSP) from the responder and the application phase begins.
  • a session reaches the application stage, where either the responder or the requestor may send application data once the handshake is complete and all validations have passed.
  • the application phase ends, for example, when an end request (END_SESSION) is issued by the requester or when an error occurs.
  • the next stage is the session termination stage.
  • the session termination phase for example, is just an internal phase and there are no explicit messages sent or received. Both the requestor and responder discard or clean up session keys, such as all derived session secrets and encryption keys, when the session ends. Requestors and responders may have other internal data associated with this session that they may also wish to clean up.
  • the session secret is used, for example, to derive the encryption key and salt used in the AEAD (Authenticated Encryption with Additional Data) function. Encryption key derivation may frequently use HMAC as defined in RFC2104 and HKDF-Expand described in RFC5869.
  • a session secret may consist of a single secret or multiple types of secrets.
  • a session key may consist of a single key or multiple types of keys.
  • FIG. 78 is a flowchart describing a first processing example of communication processing.
  • the extended mode compatible CSI-2 receiving circuit 1322 of the application processor 1212 has the functions of a CCI host (requester) and a CSI-2 host.
  • the extension mode compatible CSI-2 transmission circuit 1304 of the image sensor 1211 has the functions of a CCI device (responder) and a CSI-2 device.
  • the CCI host sends a request message to the CCI device, and upon receipt, the CCI device sends a response message to the CCI host.
  • step S501 a GET_VERSION request and a VERSION response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304.
  • the extended mode compatible CSI-2 receiving circuit 1322 acquires the SPDM (Security Protocol and Data Model) version of the endpoint.
  • step S502 a GET_CAPABILITIES request and a CAPABILITIES response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304. Thereby, the extended mode compatible CSI-2 receiving circuit 1322 acquires the SPDM function of the endpoint.
  • step S503 a NEGOTIATE_ALGORITHMS request and an ALGORITHMS response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304.
  • the extended mode compatible CSI-2 receiving circuit 1322 negotiates with the extended mode compatible CSI-2 transmitting circuit 1304 on the encryption algorithm.
  • step S504 a PSK_EXCHANGE request and a PSK_EXCHANGE_RSP response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304.
  • extended mode compatible CSI-2 receiving circuit 1322 and extended mode compatible CSI-2 transmitting circuit 1304 derive session keys for CCI such as session secrets and encryption keys.
  • step S505 a PSK_FINISH request and a PSK_FINISH_RSP response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304. This proves to the responder that the extension mode compatible CSI-2 receiving circuit 1322 knows the PSK (PSK: Pre-shared key) and that the session key for CCI derived in step S504 is correct.
  • PSK PSK: Pre-shared key
  • step S506 a PSK_EXCHANGE request and a PSK_EXCHANGE_RSP response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304.
  • extended mode CSI-2 receiving circuit 1322 and extended mode CSI-2 transmitting circuit 1304 derive session keys for CSI-2 such as session secrets and encryption keys.
  • step S507 a PSK_FINISH request and a PSK_FINISH_RSP response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304. This proves to the responder that the extension mode compatible CSI-2 receiving circuit 1322 knows the PSK (PSK: Pre-shared key) and that the session key for CSI-2 derived in step S506 is correct.
  • PSK PSK: Pre-shared key
  • the proof of the session key in steps S505 and S507 is realized by the MAC value calculated from the requester's finished_key and the message of this session.
  • the session keys derived in steps S504 and S506 are then used to protect subsequent CCI and CSI-2 communications.
  • step S508 the extended mode compatible CSI-2 receiving circuit 1322 supplies the CSI-2 session secret, session key, algorithm, and other parameters from the CCI host to the CSI-2 host.
  • step S509 the extended mode compatible CSI-2 transmission circuit 1304 supplies the CSI-2 session secret, session key, algorithm, and other parameters from the CCI device to the CSI-2 device.
  • step S510 the CSI-2 device of the extended mode compatible CSI-2 transmitting circuit 1304 transmits image data to the extended mode compatible CSI-2 receiving circuit 1322 of the CSI-2 host by high-speed data communication. For example, high-speed data communication continues until it is time to update the session key for CSI-2.
  • step S511 the extended mode compatible CSI-2 receiving circuit 1322 supplies a trigger for updating the CSI-2 session key from the CSI-2 host to the CCI host.
  • a CSI-2 device or a CCI device may provide a trigger to the CCI host, or a CCI host may provide a self-trigger to the CCI host.
  • a KEY_UPDATE request and a KEY_UPDATE_ACK response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304. This updates the session key and discards part of the old session key. Note that when the session key is composed of multiple types of keys (request direction key, response direction key, etc.), some or all of them may be updated.
  • a KEY_UPDATE request may also be issued by a responder using the GET_ENCAPSULATED_REQUEST mechanism described below.
  • step S513 the same processing as step S512 is performed, and the KEY_UPDATE request and KEY_UPDATE_ACK response are performed twice. As a result, the rest (all) of the old session keys that have not been discarded by the process of step S512 alone are discarded.
  • step S514 the extended mode compatible CSI-2 receiving circuit 1322 supplies the CSI-2 session secret, session key (after update), algorithm, and other parameters from the CCI host to the CSI-2 host. .
  • step S515 in the extended mode compatible CSI-2 transmission circuit 1304, the CCI device supplies the CSI-2 device with a session secret for CSI-2, a session key (after updating), an algorithm, and other parameters. .
  • step S516 as in step S510, transmission of image data by high-speed data communication is started, and the same processes as in steps S510 to S515 are repeated.
  • the session key for CCI and the session key for CSI-2 are different, and the session ID for CCI and for CSI-2 are different. and CSI-2 have different session secrets.
  • the session key for CCI and the session key for CSI-2 may be the same.
  • the session ID may be the same for both CCI and CSI-2, and the session secret may be the same for CCI and CSI-2.
  • FIG. 79 is a flowchart describing a second processing example of communication processing.
  • steps S521 to S523 processing similar to steps S501 to S503 in FIG. 78 is performed.
  • step S524 a PSK_EXCHANGE request and a PSK_EXCHANGE_RSP response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304.
  • the same session secret is derived for CCI and CSI-2.
  • the session key for CCI and the session key for CSI-2 can be derived from the same session secret.
  • the session key for uplink and the session key for downlink (reverse direction of uplink) may be derived from the same session secret.
  • a common session key for CCI and CSI-2 may be derived from the same session secret. Even if the session is the same for CCI and for CSI-2, the session secret, session key, etc. may be different between for CCI and for CSI-2.
  • steps S525 to S534 the same processing as steps S507 to S516 in FIG. 78 is performed.
  • the pre-shared key PSK key exchange scheme provides options for the requestor and responder to perform mutual authentication and session key establishment with symmetric key cryptography. This option is especially useful for endpoints that do not support asymmetric key cryptography or certificate processing. This option can also be leveraged to expedite session key establishment even when asymmetric key cryptography is supported. This option requires the requestor and responder to have prior knowledge of a common PSK prior to the handshake.
  • PSK functions as a basis for mutual authentication credentials and session key establishment. As such, only the two endpoints and potentially trusted third parties provisioning PSKs to the two endpoints may know the value of the PSK.
  • a requestor may be paired with multiple responders. Similarly, a responder may be paired with multiple requestors. A requestor and responder pair may be provisioned with one or more PSKs.
  • An endpoint may act as a requester for one device and at the same time as a responder for another device.
  • the transport layer needs to identify the peer and establish communication between the two endpoints before PSK-based session key exchange can begin.
  • a PSK may be provisioned within a trusted environment, such as during a secure manufacturing process.
  • a PSK may be agreed between two endpoints using a secure protocol in an untrusted environment.
  • the provisioned PSK size is determined by the security strength requirements of the application, but should be at least 128 bits, preferably at least 256 bits.
  • endpoint capabilities and supported algorithms may be communicated to peers. Therefore, the SPDM commands GET_CAPABILITIES and NEGOTIATE_ALGORITHMS are not required during session key establishment using the PSK option.
  • PSK_EXCHANGE/PSK_EXCHANGE_RSP PSK_FINISH/PSK_FINISH_RSP.
  • the PSK_EXCHANGE message includes the role of prompting the responder to obtain a specific PSK, the role of exchanging context between the requester and responder, and the requester's role that the responder knows the correct PSK and has derived the correct session key. There are three roles: the role of proving.
  • FIG. 80 is a flowchart describing a third processing example of communication processing.
  • steps S541 to S543 processing similar to steps S501 to S503 in FIG. 78 is performed.
  • step S544 a GET_DIGESTS request and a DIGESTS response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304.
  • the extended mode compatible CSI-2 receiving circuit 1322 acquires the certificate chain digest from the extended mode compatible CSI-2 transmitting circuit 1304 .
  • step S545 a GET_CERTIFICATE request and a CERTIFICATE response are made between the CCI host of the CSI-2 receiving circuit 1322 supporting extended mode and the CCI device of the CSI-2 transmitting circuit 1304 supporting extended mode.
  • the extended mode compatible CSI-2 receiving circuit 1322 acquires the certificate chain from the extended mode compatible CSI-2 transmitting circuit 1304 . It should be noted that acquisition of the certificate chain may be executed multiple times.
  • step S546 a CHALLENGE request and a CHALLENGE_AUTH response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304. This allows the extended mode CSI-2 receiving circuit 1322 to authenticate the extended mode CSI-2 transmitting circuit 1304 through the challenge-response protocol.
  • This initiates a handshake between the requestor and responder for the purpose of authenticating the responder (or optionally both parties).
  • Encryption parameters are then negotiated in addition to what was negotiated in the final NEGOTIATE_ALGORITHMS/ALGORITHMS exchange, and shared key information is established.
  • step S548 the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 transmits GET_ENCAPSULATED_REQUEST to the extended mode compatible CSI-2 transmitting circuit 1304 CCI device.
  • step S549 the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304 transmits ENCAPSULATED_REQUEST (GET_DIGESTS request) to the extended mode compatible CSI-2 receiving circuit 1322 CCI host.
  • ENCAPSULATED_REQUEST GET_DIGESTS request
  • step S550 the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 transmits DELIVER_ENCAPSULATED_RESPONSE (DIGESTS response) to the extended mode compatible CSI-2 transmitting circuit 1304 CCI device.
  • DIGESTS response DELIVER_ENCAPSULATED_RESPONSE
  • the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304 acquires the certificate chain digest from the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 .
  • step S551 the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304 transmits ENCAPSULATED_RESPONSE_ACK (GET_CERTIFICATE request) to the extended mode compatible CSI-2 receiving circuit 1322 CCI host.
  • ENCAPSULATED_RESPONSE_ACK GET_CERTIFICATE request
  • step S552 the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 transmits DELIVER_ENCAPSULATED_RESPONSE (CERTIFICATE response) to the extended mode compatible CSI-2 transmitting circuit 1304 CCI device.
  • the CCI device (responder) may obtain the certificate chain from the CCI host (requestor). Note that this process may be executed multiple times.
  • step S553 the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304 transmits ENCAPSULATED_RESPONSE_ACK to the extended mode compatible CSI-2 receiving circuit 1322 CCI host.
  • step S554 a FINISH request and a FINISH_RSP response are made between the CCI host of the CSI-2 receiving circuit 1322 supporting extended mode and the CCI device of the CSI-2 transmitting circuit 1304 supporting extended mode. This completes the handshake between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304 initiated by the KEY_EXCHANGE request in step S547.
  • step S555 a GET_MEASUREMENTS request and a MEASUREMENTS response are made between the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 and the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304.
  • the CCI host of the extended mode compatible CSI-2 receiving circuit 1322 acquires the measurement data from the CCI device of the extended mode compatible CSI-2 transmitting circuit 1304 .
  • the GET_MEASUREMENTS request may be issued by the responder using the GET_ENCAPSULATED_REQUEST mechanism described above.
  • other requests may be issued from the responder using the GET_ENCAPSULATED_REQUEST mechanism described above.
  • the extended packet consists of a packet header PH, an extended packet header ePH, packet data, an extended packet footer ePF, and a packet footer PF.
  • An extension packet configured in this way can be used to specify frame start, embedded data, image data, user-defined data, frame end, write command (CCI Write), read command (CCI Read), and read response (CCI Read return value). Can be configured. Some or all of the packet header PH, extended packet header ePH, packet data, extended packet footer ePF, and packet footer PF may be omitted. That is, a packet configuration including at least an extended packet header ePH and packet data is defined as an extended packet.
  • any of the extended packet header ePH, packet data, or extended packet footer ePF may not be received normally (messages may be lost) due to noise, interference, or attacks. Therefore, it is desirable to store a verification packet for verifying the integrity of the extension packet header ePH, the packet data, and the extension packet footer remainder ePF1 in the extension packet footer end ePF0.
  • CRC32 of a cyclic redundancy check which is a kind of error detection code, is used.
  • Packet data can be used for the packet to be verified.
  • an extended packet header and packet data can be used for the packet to be verified.
  • packet data and extended packet footer rest (ePF1) can be used for the packet to be verified.
  • the packet to be verified can use the extended packet header, packet data and extended packet footer rest (ePF1). At least the packet data is protected by such a verified packet.
  • the image sensor 1211 includes a second protection unit (eg, CRC calculation unit) that generates second protection data (eg, CRC calculation value) of packet data without using a session key.
  • the second protected data is stored, for example, in an extended packet footer ePF for high speed data transmission. That is, within the frame start, embedded data, image data, user-defined data, frame end, write command (CCI Write), read command (CCI Read), read response (CCI Read return value), etc. is stored in either
  • Security features may be defined for extended packet footers ePF1 and ePF0.
  • the image sensor 1211 may include a security calculation unit (for example, an encryption calculation unit, a decryption calculation unit, a hash value calculation unit, a message authentication code calculation unit, and a digital signature calculation unit).
  • the result of the security calculation (eg hash value, message authentication code, digital signature) may then be stored in the extended packet footer ePF.
  • the result of the security operation may be stored only within the extended packet footer ePF1 rather than within the extended packet footer ePF0, or may be stored outside the extended packet footer rather than within the extended packet footer (e.g., embedded in the data or in the read response).
  • a security calculation unit included in the image sensor 1211 is included in the security unit 1310 .
  • GMAC GaloisMAC
  • CMAC Cipher-based MAC
  • HMAC Hash-based MAC
  • MAC message authentication code
  • AES-GMAC AES-GMAC
  • AES-CMAC SHA2-HMAC
  • SHA3-HMAC SHA3-HMAC
  • AES Advanced Encryption Standard
  • SHA Secure Hash Algorithm
  • the extended packet footer for example, either the packet data as the packet to be verified, or the extended packet header and the packet data as the packet to be verified, a hash (especially a cryptographic hash) value, a message authentication code, a digital signature, etc. of security information may be stored. In that case, it is possible to provide further resistance to malicious tampering by an attacker.
  • a CRC of a cyclic redundancy check which is a type of error detection code, may be stored in the extension packet footer "ePF1" or "ePF1 and ePF0".
  • an integrity calculation value for example, second 1 protected data, 2nd protected data
  • the CRC can be used for functional safety and its integrity can be used to prevent hardware failures from going undetected.
  • the integrity of security functions can be used to detect intentional interference or attacks. That is, the security calculation unit calculates an integrity calculation value based on encryption, and the CRC calculation unit calculates an integrity calculation value not based on encryption.
  • the application processor 1212 can verify the integrity of the packet to be verified, for example, by using the verification packet.
  • it is determined to be abnormal for example, transmission of a request message requesting retransmission of a packet including a packet to be verified and a verification packet, transmission of a request message inquiring of the image sensor 1211 whether there is an abnormality in the image sensor 1211, transmission of a request message to the image sensor 1211, Send a request message requesting the image sensor 1211 to stop part or all of the functions of 1211, stop the propulsion device, change the propulsion control of the propulsion device, change the priority data used for propulsion control, etc. may be performed.
  • the integrity calculation value is stored, for example, in embedded data, image data (packet data), user-defined data, a write command, a read command, a read response, or the like.
  • the integrity computation value may not be stored in the extended packet footer.
  • the computed completeness values may be stored per image frame rather than per image line, in which case the completeness is computed efficiently.
  • the integrity calculation value is stored, for example, in the embedded data or in the read response after the image data has been sent.
  • the expansion packet shown in A of FIG. 81 is an expansion packet in which the calculation value obtained by the security calculation using the verification packet is stored with the expansion packet header ePH, the packet data, and the expansion packet footer remainder ePF1 as the verification packet.
  • This is a configuration example in which ePF0 at the end of the footer is a verification packet.
  • the extension packet shown in B of FIG. 81 uses the packet data and the remainder of the extension packet footer ePF1 as the packet to be verified, and the extension packet footer end ePF0 that stores the calculated value obtained by the security calculation using the packet to be verified is used for verification.
  • This is a configuration example of a packet.
  • the expansion packet shown in C of FIG. 81 is a verification packet with the expansion packet header ePH and packet data as the verification packet, and the expansion packet footer end ePF0 storing the calculated value obtained by the security calculation using the verification packet. This is a configuration example.
  • the expansion packet shown in D of FIG. 81 is a configuration example in which the packet data is the packet to be verified, and ePF0 at the end of the expansion packet footer storing the calculated value obtained by the security calculation using the packet to be verified is the verification packet. It's becoming
  • the expansion packet shown in A of FIG. 82 is a verification packet with the expansion packet header ePH and packet data as the verification packet, and the expansion packet footer remainder ePF1 storing the calculated value obtained by the security calculation using the verification packet. This is a configuration example.
  • the extension packet shown in B of FIG. 82 is an extension packet footer remainder ePF1 and an extension packet footer in which calculation values obtained by security calculation using the extension packet header ePH and packet data are stored as a verification packet.
  • This is a configuration example in which the tail ePF0 is a verification packet.
  • the expansion packet shown in FIG. 82C is a configuration example in which the packet data is the packet to be verified, and the expansion packet footer remainder ePF1 storing the calculated value obtained by the security calculation using the packet to be verified is the verification packet. It's becoming
  • the extension packet shown in D of FIG. 82 uses the packet data as the packet to be verified, and uses the extension packet footer remainder ePF1 and the extension packet footer end ePF0, which store the calculated values obtained by the security calculation using the packet to be verified, for verification.
  • This is a configuration example of a packet.
  • FIG. 83 is a flowchart for explaining data verification processing performed in the application processor 1212.
  • FIG. 83 is a flowchart for explaining data verification processing performed in the application processor 1212.
  • step S601 when the extension packet transmitted from the image sensor 1211 is received by the extension mode compatible CSI-2 receiving circuit 1322, the security unit 1326 receives the verification packet of the extension packet.
  • the process proceeds to step S602. Note that even if all of the packets to be verified have not been completely received, the process may proceed to step S602 as long as at least a portion (for example, 128 bits) capable of starting calculation of the security calculation has been received. . In that case, the remaining to-be-verified packets continue to be received until all of the to-be-verified packets have been received.
  • step S602 the security unit 1326 starts calculating a calculated value obtained by security calculation using at least part of the packet to be verified received in step S601.
  • step S603 the security unit 1326 receives the verification packet transmitted from the image sensor 1211 via the extended mode compatible CSI-2 receiving circuit 1322.
  • the security unit 1326 completes the reception of the verification packet and acquires the received value (calculated value calculated by the image sensor 1211) stored in the verification packet, the process proceeds to step S604.
  • step S604 the security unit 1326 completes the calculation of the calculated value obtained by the security calculation using the packet to be verified that started in step S602 (that is, receives all of the packet to be verified and calculates using all of it). is completed), the process proceeds to step S605.
  • step S605 the security unit 1326 determines whether or not the received value received in step S603 matches the calculated value obtained in step S604.
  • step S605 If the security unit 1326 determines in step S605 that the received value and the calculated value match, the process proceeds to step S606. In this case, in step S606, the security unit 1326 determines that the extended packet received by the extended mode compatible CSI-2 receiving circuit 1322 is normal, and the process ends.
  • step S605 determines that the received value and the calculated value do not match
  • the process proceeds to step S607.
  • step S607 the security unit 1326 determines that the extension packet received by the extension mode compatible CSI-2 receiving circuit 1322 is abnormal, and the process ends.
  • the image sensor 1211 stores the message count value counted by the message counter 1308 in the extended packet header or the extended packet footer in order to ensure functional safety (e.g., detecting missing messages and taking appropriate action). can do.
  • the message counter 1308 included in the image sensor 1211 can store a message count value that is incremented or decremented each time a message is sent from the image sensor 1211 .
  • the image sensor 1211 may have a configuration in which an independent message counter 1308 is provided for each virtual channel, or a configuration in which a common message counter 1308 is provided for the virtual channels.
  • Message counter 1308 sets the message count value to an initial value (e.g., 0 or a maximum value) on the first packet that includes an extended packet header for a given virtual channel, and each time it sends data that includes an extended packet header for a given virtual channel. to increment or decrement the message count value. Also, the message counter 1308 does not increment or decrement the message count value, for example, when data that does not include an extended packet header is transmitted, and increments the count the next time data that includes an extended packet header is transmitted. resume.
  • an initial value e.g., 0 or a maximum value
  • the message counter 1308 may continue counting regardless of frame start or frame end. Then, when the message count value counts up to a specified value (eg, maximum value or 0), the message counter 1308 returns the next message count value to the initial value (eg, 0 or maximum value) and counts. . Note that part of the extended packet header may store part of the nonce value.
  • the receiving side image sensor 1211 or application processor 1212
  • the message count value is preferably stored within the extended packet header.
  • the receiving side can start responding to them in a short time. For example, high speed movement or high speed movement is possible. It is particularly suitable for a propulsion device with a
  • a write command (CCI Write), a read command (CCI Read), or a read response (CCI Read return value) may also be configured to store a message count value or an integrity calculation value, and an extension packet may apply. In that case, it becomes possible to support functional safety and protect integrity for write commands, read commands, and read responses.
  • FIG. 84 is a flowchart for explaining message count value transmission processing in which the image sensor 1211 transmits the message count value.
  • step S611 the message counter 1308 initializes the message count value to 0.
  • step S612 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit the extension packet header, and the process waits until it is determined to transmit the extension packet header. Then, in step S612, if the extension mode compatible CSI-2 transmission circuit 1304 determines to transmit the extension packet header, the process proceeds to step S613.
  • step S613 the extension mode compatible CSI-2 transmission circuit 1304 acquires the message count value from the message counter 1308 and stores it in the extension packet header.
  • the extended mode compatible CSI-2 transmission circuit 1304 transmits the extended packet header containing the message count value at step S613.
  • step S615 the message counter 1308 determines whether the message count value has reached the maximum value. If the message counter 1308 determines in step S615 that the message count value has not reached the maximum value, processing proceeds to step S616.
  • step S616 the message counter 1308 increments the message count value. After that, the process returns to step S612, and the same process is repeated thereafter.
  • step S615 determines in step S615 that the message count value has reached the maximum value
  • the process returns to step S611 to initialize the message count value, and then repeats the same process. done.
  • the message count value may be initialized, set to the maximum value, and decremented.
  • the image sensor 1211 can include additional information such as device setting information in the data stream.
  • the embedded data consists of one or more lines and includes any of configuration data of the image sensor 1211, standard register values, vendor specific register values, frame format descriptions, statistical values, etc. is possible.
  • FIG. 85A shows one line of embedded data, in which the embedded data format code is followed by a desired amount of embedded data, and the remaining padding characters. It has a configuration.
  • Embedded data includes information related to image data or user-defined data. Therefore, although the image data or user-defined data may be compressed data, it is desirable that the embedded data be uncompressed data (uncompressed data). Therefore, when data compression is used, compressed data (image data or user-defined data) and non-compressed data (embedded data) are mixed in a frame of high-speed data transmission.
  • the embedded data can have multiple embedded data lines (rows) according to the number of register values added to the embedded data. Also, the number of rows of embedded data can be specified by part of the description within the frame format in the first row of embedded data within the frame.
  • the line length of the embedded data may be shorter than the line length of the image data or user-defined data, but should not exceed the line length of the image data or user-defined data. preferably identical.
  • a first pixel value of the embedded data may indicate the format used for the embedded data.
  • Part or all of the nonce value is stored and transmitted within at least part of the embedded data indicating a vendor specific code or a reserved code (Reserved for future use) as shown in FIG. 85B. good too.
  • embedded data is stored either between the frame start and the first image data or user-defined data, and between the last image data or user-defined data and the frame end. However, embedded data between the last image data or user-defined data and the frame end may be omitted.
  • FIG. 86 shows an example of the data structure of two frames of image data transmitted from the image sensor 1211.
  • FIG. 86 shows an example of the data structure of two frames of image data transmitted from the image sensor 1211.
  • the read command and read response are followed by the frame start (VC2 FS) of the second virtual channel.
  • the first embedded data (VC1 Emb Data) of the first virtual channel and the first embedded data (VC2 Emb Data) of the second virtual channel are transmitted.
  • one frame of image data (VC1 Img Data) of the first virtual channel and user-defined data (VC2 UD Data) of the second virtual channel are transmitted.
  • the second embedded data (VC1 Emb Data) of the first virtual channel and the second embedded data (VC2 Emb Data) of the second virtual channel are transmitted.
  • the end of frame (VC1 FE) of the first virtual channel is transmitted
  • the end of frame (VC2 FE) of the second virtual channel is transmitted following the read command and read response.
  • FIG. 86 shows an example in which the message count value is shared between the first virtual channel and the second virtual channel.
  • the configuration may be such that independent sage counters are provided for the first virtual channel and the second virtual channel.
  • the user-defined data may be image data or the like.
  • part or all of the nonce value is stored, for example, within the period from the frame start to the frame end or within the period from the frame end to the frame start (frame blanking period).
  • the nonce value can be stored within the period from the frame start to the frame end, for example, within embedded data, within image data, within non-image data, or within a line blanking period. It may also be stored in a second virtual channel.
  • embedded data is data in which attributes representing image data, information (metadata) related to image data, and the like are stored.
  • High-speed data transmission and low-speed command transmission can be frequency-separated by a filter, so if power consumption is not a problem, part or all of the transmission may be duplicated (parallel execution).
  • Some or all of the nonce values may be sent every multiple frames, but are preferably sent every frame, for example due to missing frames.
  • FIG. 87 is a flowchart describing image data transmission processing in which the image sensor 1211 transmits image data.
  • step S621 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not a command to start high-speed data transmission has been received, and processing is put on standby until it is determined that a command to start high-speed data transmission has been received. be. If it is determined in step S621 that the extension mode compatible CSI-2 transmission circuit 1304 has received a command to start high-speed data transmission, the process proceeds to step S622.
  • step S622 the pixel 1301 starts imaging, and the image data output from the pixel 1301 is supplied to the extension mode compatible CSI-2 transmission circuit 1304 via the AD converter 1302 and the image processing unit 1303.
  • step S623 the extension mode compatible CSI-2 transmission circuit 1304 transmits the frame start of the first virtual channel.
  • step S624 the extension mode compatible CSI-2 transmission circuit 1304 transmits the frame start of the second virtual channel.
  • step S625 the extended mode compatible CSI-2 transmission circuit 1304 transmits the first embedded data of the first virtual channel.
  • step S626 the extended mode compatible CSI-2 transmission circuit 1304 transmits the first embedded data of the second virtual channel.
  • step S627 the extension mode compatible CSI-2 transmission circuit 1304 transmits the image data of the first virtual channel.
  • step S628 the extended mode compatible CSI-2 transmission circuit 1304 transmits user-defined data on the second virtual channel.
  • step S629 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not transmission of image data for one frame has been completed.
  • step S629 If the extended mode compatible CSI-2 transmission circuit 1304 determines in step S629 that the transmission of one frame of image data has not been completed, the process returns to step S627, and the same process is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S629 that transmission of one frame of image data has been completed, the process proceeds to step S630.
  • step S630 the extended mode compatible CSI-2 transmission circuit 1304 transmits the second embedded data of the first virtual channel.
  • step S631 the extended mode compatible CSI-2 transmission circuit 1304 transmits the second embedded data of the second virtual channel.
  • step S632 the extension mode compatible CSI-2 transmission circuit 1304 transmits the frame end of the first virtual channel.
  • step S633 the extension mode compatible CSI-2 transmission circuit 1304 transmits the frame end of the second virtual channel.
  • step S634 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not a command to end high-speed data transmission has been received.
  • step S634 If it is determined in step S634 that the extended mode compatible CSI-2 transmission circuit 1304 has not received the high-speed data transmission end command, the process returns to step S622, and the same process is repeated thereafter. On the other hand, if it is determined in step S634 that the extended mode compatible CSI-2 transmission circuit 1304 has received the high-speed data transmission end command, the process ends.
  • the start of imaging may be continuously executed until an instruction to end high-speed data transmission is received, or may be executed each time an instruction to start high-speed data transmission is received.
  • FIG. 88 is a flowchart for explaining the integrity computation value transmission process in which the image sensor 1211 transmits the integrity computation value.
  • step S641 the security unit 1310 derives the session key for the first virtual channel.
  • step S642 the security unit 1310 derives the session key for the second virtual channel.
  • step S643 the message counter 1308 initializes the upper count value of the message count value and sets it to zero.
  • step S644 the message counter 1308 initializes the lower count value of the message count value and sets it to zero.
  • step S645 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to end the session, and if it is determined not to end the session, the process proceeds to step S646.
  • step S646 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit the extension packet of the first virtual channel.
  • step S646 If it is determined in step S646 that the extension mode compatible CSI-2 transmission circuit 1304 does not transmit the extension packet of the first virtual channel, the processing returns to step S645, and the same processing is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S646 to transmit the extension packet of the first virtual channel, the process proceeds to step S647.
  • step S647 the security unit 1310 uses the session key of the first virtual channel derived in step S641 to calculate the integrity calculation value of the first virtual channel.
  • step S648 the extension mode compatible CSI-2 transmission circuit 1304 arranges the integrity calculation value calculated in step S647 in the extension packet of the first virtual channel, and transmits the extension packet of the first virtual channel. .
  • step S649 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit the extension packet of the second virtual channel, and continues processing until it is determined to transmit the extension packet of the second virtual channel. stand by. Then, in step S649, if the extension mode compatible CSI-2 transmission circuit 1304 determines to transmit the extension packet of the second virtual channel, the process proceeds to step S650.
  • step S650 the security unit 1310 uses the session key of the second virtual channel derived in step S642 to calculate the integrity calculation value of the second virtual channel.
  • step S651 the extension mode compatible CSI-2 transmission circuit 1304 arranges the integrity calculation value calculated in step S650 in the extension packet of the second virtual channel, and transmits the extension packet of the second virtual channel.
  • step S652 the message counter 1308 determines whether or not the lower count value of the message count value has reached the maximum value.
  • step S652 determines in step S652 that the lower count value of the message count value has not reached the maximum value. If the message counter 1308 determines in step S652 that the lower count value of the message count value has not reached the maximum value, the process proceeds to step S653. In step S653, the message counter 1308 increments the lower count value of the message count value, then the process returns to step S645, and the same process is repeated thereafter.
  • step S652 determines in step S652 that the lower count value of the message count value has reached the maximum value.
  • the process proceeds to step S654.
  • step S654 message counter 1308 increments the upper count value of the message count value, and then the process returns to step S644, and the same process is repeated thereafter.
  • step S645 if the extension mode compatible CSI-2 transmission circuit 1304 determines to end the session, the process proceeds to step S655.
  • step S655 the security unit 1310 destroys or cleans up the session key of the first virtual channel and the session key of the second virtual channel, after which the process ends.
  • FIG. 89 shows a first modified example of the data structure of image data.
  • the data structure of the image data shown in FIG. 89 uses a common message count value for the first virtual channel and the second virtual channel.
  • session key or message counter may be shared between the first virtual channel and the second virtual channel.
  • image data or embedded data may be replaced with other data.
  • embedded data may be replaced with image data.
  • message counters may be shared by counting across virtual channels (VCs).
  • FIG. 90 shows a second modification of the data structure of image data.
  • independent message count values are used for Write (CCI write command), Read1 (CCI read command), and Read2 (CCI read response).
  • FIG. 91 shows a third modified example of the data structure of image data.
  • independent message count values are provided for the CCI uplink (Write and Read1) and the CCI downlink (Read2). That is, the message count value may be shared between Write (CCI write instruction) and Read1 (CCI read instruction).
  • the nonce value is used as part or all of the initialization vector for encryption or decryption operations using the session key, for example, because it is number used once for the same session key. Therefore, the nonce used by the image sensor 1211 for the encryption operation is transmitted from the image sensor 1211 and received by the application processor 1212, so that the application processor 1212 can obtain the nonce value required for the decryption operation.
  • the image sensor 1211 desirably transmits a nonce value before transmitting image data.
  • part or all of the nonce value corresponding to the image data in a certain frame is the first image data in a certain frame after the last image data in the frame was completely transmitted one before.
  • within the read response within the user-defined data, within the embedded data (immediately after the image data), within the frame end, within the frame start, within the embedded data (immediately before the image data), etc. stored in
  • the application processor 1212 which is the master of low-speed command transmission, receives frame start, embedded data, image data, user-defined data, frame end, etc., transmitted by high-speed data transmission from the image sensor 1211, which is the slave of low-speed command transmission.
  • a read command requesting the application processor 1212 to read the nonce value in the image sensor 1211 may be transmitted by low-speed command transmission in response to the start or completion of reception of any of the above.
  • the image sensor 1211 receives the readout command sent from the application processor 1212 and sends the corresponding nonce value by high-speed data transmission.
  • the image sensor 1211 can notify the application processor 1212 of the nonce value.
  • This read command for example, corresponds to Read of Read/Write in the I2C or I3C standard.
  • the read response corresponds to the read return value.
  • a timer may be provided that waits for a predetermined period of time after the application processor 1212 receives the high-speed data transmission and before it transmits the read command.
  • the inter-integrated circuit serial bus sometimes called the I2C bus or I 2 C bus, is a serial single-ended computer bus intended for use in connecting low speed peripherals to application processor 1212 .
  • the I2C bus is a multi-master bus in which each device can act as master and slave to different messages sent on the I2C bus.
  • the I2C bus can transmit data using only two bidirectional open-drain connectors, including the serial data line (SDA) and serial clock line (SCL). Those connectors typically include signal lines terminated by pull-up resistors.
  • SDA serial data line
  • SCL serial clock line
  • Those connectors typically include signal lines terminated by pull-up resistors.
  • the protocol that governs the operation of the I2C bus defines basic types of messages, each of which begins with a START and ends with a STOP.
  • the I2C bus uses 7-bit addressing and defines two types of nodes.
  • a master node is a node that generates a clock and initiates communication with slave nodes.
  • a slave node is a node that receives a clock and responds when addressed by a master.
  • the I2C bus is a multi-master bus, which means that there can be any number of master nodes. Additionally, the master and slave roles may change between messages (ie, after a STOP is sent). In this embodiment, which is a camera implementation, one-way transmission may be used to capture images from the sensor and transmit such image data to memory in the baseband processor, while the baseband processor and , sensors as well as other peripheral devices.
  • the Camera Control Interface (CCI) protocol may be used for such control data between the baseband processor and the image sensor (or one or more slave nodes).
  • the CCI protocol may be implemented over an I2C serial bus between the image sensor and the baseband processor.
  • I2C serial bus between the image sensor and the baseband processor.
  • the I3C communication standard is a standard for communication via two signal lines, the SDA line for transmitting data and the SCL line for transmitting clock signals.
  • devices such as processors
  • devices are classified into devices that operate as masters or slaves, and devices that operate only as slaves.
  • a processor can act as a master or a slave, and a sensor can only act as a slave.
  • a master is a device that controls a slave
  • a slave is a device that operates under the control of the master.
  • a plurality of slaves can be connected to one master.
  • multiple masters can transmit signals to one slave, and this communication is hereinafter referred to as "multi-master communication”.
  • slaves can communicate with each other without going through the master, and this communication is called “peer-to-peer communication”.
  • peer-to-peer communication while the SDA line is busy with communication from another device, the slave can interrupt the communication and perform communication. is called.
  • signals transmitted simultaneously by multiple devices may collide on the SDA line. For example, if a master is sending a signal to a slave and another slave has an in-band interrupt and is sending a signal to the master, the signals from the master and slaves will collide. Therefore, devices in I3C have a function of detecting collisions and arbitrating between devices.
  • the image sensor 1211 may trigger the read command with an in-band interrupt and send a read response accordingly, or may omit the read command and send a read response with an in-band interrupt.
  • FIG. 92 is a flowchart for explaining a first processing example of integrity computation value processing in which the image sensor 1211 transmits the integrity computation value.
  • step S661 the security unit 1310 derives a session key.
  • step S662 the message counter 1308 initializes the message count value to 0.
  • step S663 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to end the session, and if it is determined not to end the session, the process proceeds to step S664.
  • step S664 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit an extension packet.
  • step S664 If it is determined in step S664 that the extension mode compatible CSI-2 transmission circuit 1304 does not transmit the extension packet, the processing returns to step S663, and the same processing is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S664 to transmit an extension packet, the process proceeds to step S665.
  • step S665 the security unit 1310 uses the message count value to calculate the integrity calculation value.
  • step S666 the extension mode compatible CSI-2 transmission circuit 1304 places the integrity calculation value calculated in step S665 in the extension packet and transmits the extension packet.
  • step S667 the message counter 1308 determines whether the message count value has reached the maximum value. If the message counter 1308 determines in step S667 that the message count value has not reached the maximum value, processing proceeds to step S668.
  • step S668 the message counter 1308 increments the message count value. After that, the process returns to step S663, and the same process is repeated thereafter.
  • step S667 determines in step S667 that the message count value has reached the maximum value
  • the process proceeds to step S669.
  • the security unit 1310 updates the session key in step S669
  • the process returns to step S662, and the same process is repeated thereafter.
  • step S663 if the extension mode compatible CSI-2 transmission circuit 1304 determines to end the session, the process proceeds to step S670.
  • step S670 the security unit 1310 destroys or cleans up the session key, after which the process ends.
  • the message count value is incremented by 1 each time an extension packet is transmitted.
  • the count value circles. For example, when sending 4K data with a frame rate of 60 fps and a pixel count of 4096 x 2160 (horizontal x vertical), an extension packet of 2163 lines, which is the sum of the 3 lines of the frame start, embedded data, and frame end, is added within one frame. , the message count value goes around in (2 16 )/(60 ⁇ 2163) ⁇ 0.5 seconds.
  • the image sensor 1211 computes a MAC value such as a Galois Message Authentication Code (GMAC) value for a message using the same session key and the same initialization vector value, and sends the message and the MAC value
  • GMAC Galois Message Authentication Code
  • the attacker and the MAC value can be easily obtained by computing the simultaneous equations.
  • the attacker can freely tamper with the MAC value, attacks such as message spoofing, tampering, and replaying are possible. Therefore, if the message count value is used as the variable part of the initialization vector, that is, as the nonce value, it is necessary to update the session key before the message count value completes one cycle. For example, by utilizing the period of frame blanking or line blanking, the session key may be updated before the nonce value rolls over.
  • GMAC Galois Message Authentication Code
  • FIG. 93 is a flowchart for explaining a second processing example of integrity computation value processing in which the image sensor 1211 transmits the integrity computation value.
  • step S681 the security unit 1310 derives a session key.
  • step S682 the message counter 1308 initializes the upper count value of the message count value and sets it to zero.
  • step S683 the message counter 1308 initializes the lower count value of the message count value and sets it to zero.
  • step S684 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to end the session, and if it is determined not to end the session, the process proceeds to step S685.
  • step S685 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit an extension packet.
  • step S685 if the extension mode compatible CSI-2 transmission circuit 1304 determines not to transmit the extension packet, the process returns to step S684, and the same process is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S685 to transmit an extension packet, the process proceeds to step S686.
  • step S686 the security unit 1310 uses the upper count value and lower count value of the message count value to calculate the integrity calculation value.
  • step S687 the extension mode compatible CSI-2 transmission circuit 1304 places the integrity calculation value calculated in step S686 in the extension packet and transmits the extension packet.
  • step S688 the message counter 1308 determines whether or not the lower count value of the message count value has reached the maximum value. If message counter 1308 determines in step S688 that the lower count value of the message count value has not been counted to the maximum value, processing proceeds to step S689.
  • step S689 the message counter 1308 increments the lower count value of the message count value. After that, the process returns to step S684, and the same process is repeated thereafter.
  • step S688 determines in step S688 that the lower count value of the message count value has reached the maximum value.
  • the process proceeds to step S690.
  • message counter 1308 increments the upper count value of the message count value, and then the process returns to step S683, and the same process is repeated thereafter.
  • step S684 if the extension mode compatible CSI-2 transmission circuit 1304 determines to end the session, the process proceeds to step S691.
  • step S691 the security unit 1310 destroys or cleans up the session key, after which the process ends.
  • the message count value as part of the initialization vector, that is, part of the nonce value (eg, lower count value)
  • the rest of the nonce value eg, upper count value
  • the number of nonce values is ⁇ Using a 16-bit width upper count value: 2 32 ⁇ 60 ⁇ 2163 ⁇ 9 hours ⁇ Using a 20-bit width upper count value: 2 36 ⁇ 60 ⁇ 2163 ⁇ 6 days ⁇ Using a 24-bit width upper count value Then, 2 40 ⁇ 60 ⁇ 2163 ⁇ 98 days ⁇ 2 44 ⁇ 60 ⁇ 2163 ⁇ 4 years when combined with 28-bit width upper count value ⁇ 2 48 ⁇ 60 ⁇ 2163 ⁇ 69 years when combined with 32-bit width upper count value becomes.
  • the image sensor 1211 or the application processor 1212 is restarted (turned on after being turned off), a key exchange is required before the protected image data can be sent again. Updated. For example, in general automotive applications, the possibility of not restarting the power supply for 6 days or more is low, and the possibility of not restarting the power supply for 4 years or more is extremely low. is. Of course, it is not limited to that, and a bit width larger than that may be used.
  • the power can be turned off when refueling, and in the case of a refueling or rechargeable vehicle, if the power is turned off during vehicle inspection, the protected image data will be sent again. session keys are updated accordingly.
  • IoT Internet of Things or Intelligence of Things
  • FIG. 94 is a flowchart for explaining a third processing example of integrity computation value processing in which the image sensor 1211 transmits the integrity computation value.
  • step S701 the security unit 1310 derives a session key.
  • step S702 the message counter 1308 initializes the frame count value to 1.
  • step S703 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to end the session, and if it is determined not to end the session, the process proceeds to step S704.
  • step S704 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit an extension packet.
  • step S704 if the extension mode compatible CSI-2 transmission circuit 1304 determines not to transmit the extension packet, the process returns to step S703, and the same process is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S704 to transmit an extension packet, the process proceeds to step S705.
  • step S705 the security unit 1310 prepares the calculation of the integrity calculation value using the frame count value.
  • step S706 the extension mode compatible CSI-2 transmission circuit 1304 transmits the extension packet.
  • step S707 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not transmission within the frame other than the frame end has been completed. In step S707, if the extension mode compatible CSI-2 transmission circuit 1304 determines that transmission other than the frame end within the frame has not been completed, the process returns to step S703, and the same process is repeated thereafter. . On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S707 that the transmission within the frame other than the frame end has been completed, the process proceeds to step S708.
  • step S708 the security unit 1310 completes the calculation of the integrity calculation value using the frame count value.
  • step S709 the extension mode compatible CSI-2 transmission circuit 1304 transmits the integrity calculation value together with the frame end.
  • step S710 the message counter 1308 determines whether or not the frame count value has reached a specified value. If the message counter 1308 determines in step S710 that the frame count value has not reached the specified value, the process proceeds to step S711.
  • step S711 the message counter 1308 increments the frame count value. After that, the process returns to step S703, and the same process is repeated thereafter.
  • step S710 determines in step S710 that the frame count value has reached the specified value
  • the process proceeds to step S712.
  • the security unit 1310 updates the session key in step S712
  • the process returns to step S702, and the same process is repeated thereafter.
  • step S703 if the extension mode compatible CSI-2 transmission circuit 1304 determines to end the session, the process proceeds to step S713.
  • step S713 the security unit 1310 destroys or cleans up the session key, after which the process ends.
  • the image sensor 1211 may calculate the integrity calculation value for each image frame and transmit them collectively.
  • the integrity calculation value in that case is transmitted after being stored in the embedded data after the image data, in the user-defined data, or in the readout response.
  • a frame start or frame end may contain, for example, a 16-bit frame number. This frame number may be the same at the frame start and frame end corresponding to a given frame. When using 16-bit frame numbers, non-zero is preferred, but not required, to distinguish use cases where frame numbers do not work and are left set to zero.
  • the frame number is incremented by 1 or 2 for each frame start packet with the same virtual channel and is reset to 1 periodically. For example, if an image frame is masked (ie, not sent) due to corruption, the frame number may be incremented by two.
  • increments of 1 or 2 may be freely mixed within the sequence of frame numbers as desired. That is, when incremented by 1, the frame number goes around 2 16 -1 times. Also, when the frame rate is 60 fps, the frame number goes around in (2 16 ⁇ 1) ⁇ 60 ⁇ 18 minutes.
  • the image sensor 1211 computes a MAC value such as a Galois Message Authentication Code (GMAC) value for a message using the same session key and the same initialization vector value, and sends the message and the MAC value
  • GMAC Galois Message Authentication Code
  • the session key when using the frame number as an initialization vector, that is, as a nonce value, it is necessary to update the session key before the frame number completes its cycle. For example, by utilizing the period of frame blanking or line blanking, the session key may be updated before the nonce value rolls over.
  • FIG. 95 is a flowchart for explaining a fourth processing example of integrity computation value processing in which the image sensor 1211 transmits the integrity computation value.
  • step S721 the security unit 1310 derives a session key.
  • step S722 the message counter 1308 initializes the upper count value of the frame count value and sets it to zero.
  • step S723 the message counter 1308 initializes the lower count value of the frame count value to 1.
  • step S724 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to end the session, and if it is determined not to end the session, the process proceeds to step S725.
  • step S725 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit an extension packet.
  • step S725 If it is determined in step S725 that the extension mode compatible CSI-2 transmission circuit 1304 does not transmit the extension packet, the processing returns to step S724, and the same processing is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S725 to transmit an extension packet, the process proceeds to step S726.
  • step S726 the security unit 1310 prepares for computation of the integrity computation value using the upper count value and the lower count value of the frame count value.
  • step S727 the extension mode compatible CSI-2 transmission circuit 1304 transmits the extension packet.
  • step S728 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not transmission within the frame other than the frame end has been completed. In step S728, if the extension mode compatible CSI-2 transmission circuit 1304 determines that transmission other than the frame end within the frame has not been completed, the process returns to step S724, and the same process is repeated thereafter. . On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S728 that transmission within the frame other than the frame end has been completed, the process proceeds to step S729.
  • step S729 the security unit 1310 completes the calculation of the integrity calculation value using the upper count value and lower count value of the frame count value.
  • step S730 the extension mode compatible CSI-2 transmission circuit 1304 transmits the integrity calculation value together with the frame end.
  • step S731 the message counter 1308 determines whether the lower count value of the frame count value has reached the specified value. If the message counter 1308 determines in step S731 that the lower count value of the frame count value has not reached the specified value, the process proceeds to step S732.
  • step S732 the message counter 1308 increments the lower count value of the frame count value. After that, the process returns to step S724, and the same process is repeated thereafter.
  • step S731 determines in step S731 that the lower count value of the frame count value has reached the specified value.
  • security unit 1310 increments the upper count value of the frame count value, and then the process returns to step S723, and the same process is repeated thereafter.
  • step S724 if the extension mode compatible CSI-2 transmission circuit 1304 determines to end the session, the process proceeds to step S734.
  • step S734 the security unit 1310 destroys or cleans up the session key, after which the process ends.
  • the frame number is used as part of the initialization vector, that is, part of the nonce value (for example, the lower count value), the rest of the nonce value (for example, the upper count value) is also used to obtain the session key. , or the frequency of session key updates can be reduced.
  • the nonce value goes around - 2 4 ⁇ (2 16 -1) ⁇ 60 ⁇ 5 hours when combined with 4-bit wide upper count value 2 8 ⁇ (2 16 -1) ⁇ 60 ⁇ 78 hours when combined with 8-bit wide higher count value ⁇ 2 12 ⁇ (2 16 -1) ⁇ 60 ⁇ 52 days when using 12-bit width upper count value together ⁇ 2 16 ⁇ (2 16 -1) ⁇ 60 ⁇ 828 days when using 16-bit width upper count value together ⁇ 2 20 ⁇ (2 16 -1) ⁇ 60 ⁇ 36 years when using 20-bit width upper count value together ⁇ 2 24 ⁇ (2 16 -1) ⁇ 60 ⁇ 581 years when using 24-bit width upper count value together becomes.
  • the image sensor 1211 or application processor 1212 is restarted (turned off and then turned on), a key exchange is required before the protected image data can be sent again. Updated. For example, in general automotive applications, the possibility of not restarting the power supply for 3 days or more is low, and the possibility of not restarting the power supply for 2 years or more is extremely low. It is enough. Of course, it is not limited to that, and a bit width larger than that may be used.
  • the power can be turned off when refueling, and in the case of a refueling or rechargeable vehicle, if the power is turned off during vehicle inspection, the protected image data will be sent again.
  • session keys are updated accordingly.
  • IoT Internet of Things or Intelligence of Things
  • FIG. 96 shows an example of an initial counter block in which initialization vectors are stored.
  • a 128-bit initial counter block is used for encryption by AES (Advanced Encryption Standard)-GCM (Galois/Counter Mode) or AES-GMAC (Galois Message Authentication Code) and for message authentication.
  • AES Advanced Encryption Standard
  • GCM Galois/Counter Mode
  • AES-GMAC Galois Message Authentication Code
  • the GHASH function shown in FIG. 97 and the GCTR function shown in FIG. 98 can be used to encrypt the initial counter block.
  • the initialization vector can be encrypted using the GCM-AE (Authenticated Encryption) function having an authenticated encryption function as shown in FIG. Decryption) function is used for decryption. However, it may be used only for either encryption (decryption) or message authentication functions.
  • GCM-AE Authenticated Encryption
  • Decryption Authenticated Encryption
  • FIG. 101 shows the data structure of image data for transmitting the integrity calculation value MAC for each line.
  • a transmission scheme that transmits the integrity calculation value MAC for each line in this manner is hereinafter referred to as a line MAC scheme as appropriate.
  • the integrity calculation value MAC is sent for each CSI-2 line, each CCI command, or each CCI return.
  • the initialization vector has the same value among them, more session keys are required.
  • the first session key for uplink is used in the VC0 command and the second session key for downlink is used in VC0 return, VC1 and VC2.
  • a first session key for CCI is used in VC0 and a second session key for CSI-2 is used in VC1 and VC2.
  • one session key for all is used in VC0, VC1 and VC2.
  • a total of two message count values are used.
  • a common message count value in CSI-2 is used between VC1 and VC2, and an independent message count value in CCI is used in VC0.
  • independent message counters may be used between CSI-2 virtual channels. In that case, part of the flowchart may be deleted. In that case, message counters may be synchronized or asynchronous between virtual channels of CSI-2. For example, there are cases where it is desirable to share message counters from the viewpoint of implementation efficiency, and there are cases where it is desirable to have independent message counters from the viewpoint of security.
  • the initialization vector with the structure shown in FIG. 102 is common to all virtual channels (CSI-2 and CCI). Part or all of this initialization vector is then transmitted from the transmitting side to the receiving side as shown in FIG.
  • Reserved (Res) 2 bits specified values (for example, 0 2 , 1 2 ) may be used. Also, pre-exchanged values may be used as Source ID or Final Destination ID.
  • the receiving side may use, as a part or the whole of the initialization vector, a value that the receiving side knows instead of the value transmitted from the transmitting side to the receiving side. Also, when part or all of the initialization vector is sent from the sender to the receiver, it is desirable that part or all of the initialization vector be sent unencrypted (in plaintext), but that is not the case. do not have.
  • FIG. 103 shows an example in which the additional message count value is stored outside the extension packet header and transmitted
  • the additional message count value and the message count value may be stored and transmitted outside the extension packet header.
  • the message count value may also be stored and sent in the extended packet header. Note that only a portion of the additional message count value may be used. For example, if the additional message count value in the initialization vector is 40 bits, the actual additional message count value may be a 16-bit counter whose count value is part of the additional message count value in the initialization vector.
  • the rest of the additional message count value in the initialization vector (e.g., 24 bits on the MSB side) is stored with a specified value (e.g., 0 24 , 1 24 ). good. Also, all additional message count values in the initialization vector may be stored with default values (eg, 0 40 , 1 40 ).
  • initialization vectors that are transmitted from the image sensor 1211 to the application processor 1212 and set are configured not to be transmitted from the image sensor 1211 to the application processor 1212, based on prior agreement, register settings, or the like. may be set.
  • Fig. 104 shows an example of the extended format of CSI-2 or CCI.
  • the leading bit (Reserved and eVC) or semi-leading bit (eVC) of the mandatory extended packet header ePH0 is used as the initialization vector.
  • Application processor 1212 can then begin calculating the GCTR function shown in FIG. 98 above immediately after receiving that bit. That is, the sender and receiver may be configured to determine the values of initialization vector components other than eVC prior to sending or receiving eVC values.
  • step S741 security unit 1310 derives a common session key.
  • step S742 the message counter 1308 initializes the upper count value of the message count value and sets it to zero.
  • step S743 the message counter 1308 initializes the lower count value of the message count value and sets it to zero.
  • step S744 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to end the session, and if it is determined not to end the session, the process proceeds to step S745.
  • step S745 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit the extension packet of the first virtual channel.
  • step S745 If it is determined in step S745 that the extension mode compatible CSI-2 transmission circuit 1304 does not transmit the extension packet of the first virtual channel, the processing returns to step S744, and the same processing is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S745 to transmit the extension packet of the first virtual channel, the process proceeds to step S746.
  • step S746 the security unit 1310 uses the common session key derived in step S741 to calculate the integrity calculation value of the first virtual channel.
  • step S747 the extension mode compatible CSI-2 transmission circuit 1304 arranges the integrity calculation value calculated in step S746 in the extension packet of the first virtual channel, and transmits the extension packet of the first virtual channel. .
  • step S748 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit the extension packet of the second virtual channel, and continues processing until it is determined to transmit the extension packet of the second virtual channel. stand by. Then, in step S748, when the extension mode compatible CSI-2 transmission circuit 1304 determines to transmit the extension packet of the second virtual channel, the process proceeds to step S749.
  • step S749 the security unit 1310 uses the common session key derived in step S741 to calculate the integrity calculation value of the second virtual channel.
  • step S750 the extension mode compatible CSI-2 transmission circuit 1304 arranges the integrity calculation value calculated in step S749 in the extension packet of the second virtual channel, and transmits the extension packet of the second virtual channel. .
  • step S751 the message counter 1308 determines whether or not the lower count value of the message count value has reached the maximum value.
  • step S751 If the message counter 1308 determines in step S751 that the lower count value of the message count value has not reached the maximum value, the process proceeds to step S752. In step S752, message counter 1308 increments the lower count value of the message count value, and then the process returns to step S744, and the same process is repeated thereafter.
  • step S751 determines in step S751 that the lower count value of the message count value has reached the maximum value.
  • the process proceeds to step S753.
  • step S753 the message counter 1308 increments the upper count value of the message count value, then the process returns to step S743, and the same process is repeated thereafter.
  • step S744 if the extension mode compatible CSI-2 transmission circuit 1304 determines to end the session, the process proceeds to step S754.
  • step S754 the security unit 1310 destroys or cleans up the common session key, after which the process ends.
  • the processing described in FIG. 105 is an example in which the message count value is the lower count value and the additional message count value is the upper count value, and is an example when there are two types of CSI-2 virtual channels.
  • the initialization vector configuration may include extended data type eDT or data type DT.
  • session keys and message counters can be shared among multiple types of data types.
  • Reserved, extended virtual channel eVC, and extended data type eDT are stored as the leading bits of the CSI-2/CCI extension format example, so the processor immediately performs GCTR calculation when part or all of these are received. Some (CIPH K ) operations can be started. Also, if the frame structure is pre-agreed between the image sensor 1211 and the application processor 1212, the application processor 1212 can omit receiving these and start calculating a part of the GCTR calculation (CIPH K ). . In other words, these initialization vector configurations are advantageous in terms of computation time.
  • the application processor 1212 can use this value in the initialization vector. Accordingly, the application processor 1212 may be configured not to provide an additional message counter from the viewpoint of implementation efficiency, or may be configured to provide an additional message counter from the viewpoint of security. Also, if the application processor 1212 is configured to provide an additional message counter, the image sensor 1211 may be configured not to transmit the additional message count value. That is, if the initialization vector includes the extended virtual channel eVC, transmission of the additional message count value is not mandatory.
  • FIG. 106 shows the data structure of image data in which the integrity calculation value MAC is arranged for each frame.
  • a transmission method that transmits the integrity calculation value MAC for each frame in this manner is hereinafter referred to as a frame MAC method as appropriate.
  • the integrity computation value MAC is derived from the extended packet header ePH, packet data, and extended packet footer ePF of each line except the last extended packet footer ePF of the frame.
  • the initialization vector with the structure shown in FIG. 107 is common to line MAC and frame MAC (CSI-2 only). This initialization vector is then transmitted from the transmitting side to the receiving side as shown in FIG.
  • FIG. 108 shows an example in which the additional frame number is stored outside the extension packet header and transmitted.
  • the additional frame number and frame number may be stored outside the extended packet header and transmitted.
  • the frame number may also be stored and transmitted in the frame start. Note that only a part of the additional frame numbers may be used.
  • the extra frame number in the initialization vector is 24 bits
  • the actual extra frame number may be a 16-bit counter whose count value is part of the extra frame number in the initialization vector (e.g. 16 bits on the LSB side), and the rest of the additional frame number in the initialization vector (eg, 8 bits on the MSB side) may be stored with specified values (eg, 0 8 , 1 8 ).
  • all the additional frame numbers in the initialization vector may store prescribed values (eg, 0 24 , 1 24 ).
  • initialization vectors that are transmitted from the image sensor 1211 to the application processor 1212 and set are configured not to be transmitted from the image sensor 1211 to the application processor 1212, based on prior agreement, register settings, or the like. may be set.
  • step S761 the security unit 1310 derives a session key.
  • step S762 the message counter 1308 initializes and sets to 0 the upper count value for which the additional frame number is used.
  • step S763 the message counter 1308 initializes and sets to 1 the lower count value for which the frame number is used.
  • step S764 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to end the session, and if it is determined not to end the session, the process proceeds to step S765.
  • step S765 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit an extension packet.
  • step S765 if the extension mode compatible CSI-2 transmission circuit 1304 determines not to transmit the extension packet, the process returns to step S764, and the same process is repeated thereafter. On the other hand, if the extension mode compatible CSI-2 transmission circuit 1304 determines in step S765 to transmit an extension packet, the process proceeds to step S766.
  • step S766 the extension mode compatible CSI-2 transmission circuit 1304 transmits the extension packet.
  • step S767 the message counter 1308 determines whether the message count value has reached the maximum value.
  • step S767 If the message counter 1308 determines in step S767 that the message count value has reached the maximum value, the process proceeds to step S768. In step S768, message counter 1308 initializes the message count value to zero.
  • step S767 determines in step S767 that the message count value has not reached the maximum value. If the message counter 1308 determines in step S767 that the message count value has not reached the maximum value, the process proceeds to step S769. In step S769, message counter 1308 increments the message count value.
  • step S770 the extension mode compatible CSI-2 transmission circuit 1304 determines whether or not all extension packets in the frame have been transmitted.
  • step S770 If it is determined in step S770 that the extension mode compatible CSI-2 transmission circuit 1304 has not completed transmission of all the extension packets in the frame, the processing returns to step S764, and the same processing is repeated thereafter.
  • step S770 determines in step S770 that all extension packets in the frame have been transmitted. the process proceeds to step S771.
  • step S771 the message counter 1308 determines whether or not the lower count value has reached the specified value.
  • step S771 If the message counter 1308 determines in step S771 that the lower count value has not reached the specified value, the process proceeds to step S772. In step S772, message counter 1308 increments the lower count value, and then the process returns to step S764, and the same process is repeated thereafter.
  • step S771 determines in step S771 that the lower count value has reached the specified value
  • the process proceeds to step S773.
  • message counter 1308 increments the upper count value, and then the process returns to step S763, and the same process is repeated thereafter.
  • step S764 if the extension mode compatible CSI-2 transmission circuit 1304 determines to end the session, the process proceeds to step S774.
  • step S774 the security unit 1310 destroys or cleans up the common session key, after which the process ends.
  • the processing described with reference to FIG. 109 is an example in which the frame number is the lower count value and the additional frame number is the upper count value.
  • the computation and transmission of the integrity computation value, virtual channel, session key update, etc. are omitted, but may be combined with part or all of any of the flow charts described above. The same applies to other flowcharts.
  • the frame number may include increments of 1 or 2, so it is desirable to increment the upper count value when the lower count value is a specified value (eg, maximum value or maximum value -1). However, if the increment of the frame number is only 1, the upper count value should be incremented when the lower count value is the maximum value.
  • the application processor 1212 can use this value for the initialization vector. Therefore, the application processor 1212 may be configured not to include a frame counter from the viewpoint of implementation efficiency, or may be configured to include a frame counter from the viewpoint of safety. Also, if the application processor 1212 is configured to provide a frame counter, the image sensor 1211 may be configured not to transmit the frame number. That is, if the initialization vector contains the extended virtual channel eVC, transmission of the frame number is not an essential requirement.
  • the application processor 1212 can use this value in the initialization vector. Therefore, the application processor 1212 may be configured not to provide an additional frame counter from the viewpoint of implementation efficiency, or may be configured to provide an additional frame counter from the viewpoint of security. Also, if the application processor 1212 is configured to provide an additional frame counter, the image sensor 1211 may be configured not to transmit the additional frame number.
  • the message count value in the initialization vector may store a specified value (eg, 0 16 , 1 16 ), or a specific extension packet (eg, frame start or frame end). A message count value may be stored.
  • the message count value is stored as the message count value in the initialization vector.
  • FIG. 110 is a flowchart for explaining selection processing for the image sensor 1211 to select the transmission method of the integrity calculation value MAC.
  • step S781 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit the integrity calculation value MAC by the line MAC method.
  • step S781 If it is determined in step S781 that the extended mode compatible CSI-2 transmission circuit 1304 transmits the integrity calculation value MAC using the line MAC method, the process proceeds to step S782. In step S782, the extended mode compatible CSI-2 transmission circuit 1304 selects the line MAC method.
  • step S781 if it is determined in step S781 that the extension mode compatible CSI-2 transmission circuit 1304 does not transmit the integrity calculation value MAC using the line MAC method, the process proceeds to step S783.
  • step S783 the extended mode compatible CSI-2 transmission circuit 1304 determines whether or not to transmit the integrity calculation value MAC by the frame MAC method.
  • step S783 If it is determined in step S783 that the extended mode compatible CSI-2 transmission circuit 1304 transmits the integrity calculation value MAC using the frame MAC method, the process proceeds to step S784. In step S784, the extended mode compatible CSI-2 transmission circuit 1304 selects the frame MAC method.
  • step S783 if it is determined in step S783 that the extension mode compatible CSI-2 transmission circuit 1304 does not transmit the integrity calculation value MAC using the frame MAC method, the process proceeds to step S785.
  • step S785 the extended mode compatible CSI-2 transmission circuit 1304 selects a non-MAC scheme that does not transmit the integrity calculation value MAC.
  • step S786 the extension mode compatible CSI-2 transmission circuit 1304 transmits the security MAC information (see FIG. 111) indicating either the line MAC method, the frame MAC method, or the non-MAC method, and then the processing ends.
  • FIG. 111 shows security MAC information with 2-bit allocation, it may be allocated with a different number of bits (eg, 1 bit, 8 bits). Also, reserved area data (Reserved for future use) may be assigned not to transmit a MAC value (for example, No MAC).
  • the image sensor 1211 transmits the MAC value by the line MAC method (select the line MAC method), transmits the MAC value by the frame MAC method (selects the frame MAC method), or transmits the MAC value. It is possible to freely select whether or not to not (select the non-MAC method).
  • the image sensor 1211 may select either one upon prior agreement with the application processor 1212 .
  • the image sensor 1211 may initially select the line MAC method and switch to another method (for example, the frame MAC method) when a predetermined condition is satisfied.
  • the frame MAC method may be selected at first and switched to another method (for example, the line MAC method) when a predetermined condition is satisfied.
  • the non-MAC method may be selected at first, and then switched to another method (for example, frame MAC method) when a predetermined condition is satisfied.
  • the frame MAC method, or the non-MAC method is determined, for example, in the Security Descriptor in the extended packet header (e.g., ePH2), in the embedded data, or in the user It is stored in the definition data, read response, or the like, and is transmitted from the image sensor 1211 .
  • the application processor 1212 can respond to switching the transmission scheme of the integrity computation value MAC in response to its receipt.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本開示の一側面の情報処理装置は、第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備えている。保護部は、以下の（１）～（４）を実行する。 （１）第１セッション鍵を導出または受信すること （２）第１セッション鍵を第１通信の暗号化もしくは復号とメッセージ認証とに使用すること （３）第１セッション鍵によって保護された第１通信を使用して第２セッション鍵を受信すること （４）第２セッション鍵を第２通信の暗号化、復号またはメッセージ認証に使用すること ここで、第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、第１デバイスと第３デバイスと間の第３通信と、第１通信とにおいて互いに異なる。

Description

情報処理装置、移動体装置、および通信システム
　本開示は、情報処理装置、移動体装置、および通信システムに関し、特に、セッション鍵を使用することができるようにした情報処理装置、移動体装置、および通信システムに関する。
　現在、規格化が進行中であるCSI(Camera Serial Interface)-2 ver4.0では、物理層にC-PHYを使うパケット構造と、物理層にD-PHYを使うパケット構造との２種類が定義されている。
　近年、CSI-2規格は、モバイル機器だけに用いられるのではなく、車載やIoT（Internet of Things）など様々な用途に広く用いられるようになった。その結果、既存のパケット構造では、それらの用途に対応することができないと想定される。そこで、MIPI（Mobile Industry Processor Interface）アライアンスでは、多様な用途に対応させるため、既存のパケットヘッダやパケットフッタなどのパケット構造を拡張させた拡張パケットが検討されている。
　ところで、非特許文献１に記載のSPDM（Security Protocol and Data Model）規格においては、SPDMセッションの確立方法が公開されている。また、非特許文献２に記載のSPDM拡張規格においては、SPDMセッションの適用方法が公開されている。
"Security Protocol and Data Model (SPDM) Specification", DSP0274, Version: 1.1.0, DMTF, 2020-07-15 "Secured Messages using SPDM Specification", DSP0277, Version: 1.0.0, DMTF, 2020-09-18
　しかしながら、このSPDMセッションを利用して送信または受信されたセッション鍵をMIPIのCSI-2規格またはDSI（Display Serial Interface）-2規格の制御系通信または画像系通信に適用する場合、セッション鍵の送信側からはセッション鍵の更新タイミングが分からない、セッション鍵の受信側からはセッション鍵の使用開始タイミングが分からない、セッション鍵を使用して保護されたコマンドまたはデータなどに対してリプレイ攻撃または改竄攻撃され得る、などの問題があった。また、制御系通信または画像系通信の通信相手とセキュリティ機能を合意または選択する必要があった。また、制御系通信または画像系通信をメッセージ認証、暗号化、または復号する場合、実装上の様々な課題があった。
　本開示は、このような状況に鑑みてなされたものであり、セッション鍵を使用する情報処理装置、移動体装置、および通信システムの問題または課題を解決することができるようにしたものである。
　本開示の一側面に係る情報処理装置は、第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと第２デバイスとの間の第２通信とを保護する保護部を備えている。保護部は、以下の（１）～（４）を実行する。
（１）第１セッション鍵を導出または受信すること
（２）第１セッション鍵を第１通信の暗号化もしくは復号とメッセージ認証とに使用すること
（３）第１セッション鍵によって保護された第１通信を使用して第２セッション鍵を受信すること
（４）第２セッション鍵を第２通信の暗号化、復号またはメッセージ認証に使用すること
ここで、第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、第１デバイスと第３デバイスと間の第３通信と、第１通信とにおいて互いに異なる。
　本開示の一側面に係る移動体装置は、第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと第２デバイスとの間の第２通信とを保護する保護部を備えている。保護部は、以下の（１）～（４）を実行する。
（１）第１セッション鍵を導出または受信すること
（２）第１セッション鍵を第１通信の暗号化もしくは復号とメッセージ認証とに使用すること
（３）第１セッション鍵によって保護された第１通信を使用して第２セッション鍵を受信すること
（４）第２セッション鍵を第２通信の暗号化、復号またはメッセージ認証に使用すること
ここで、第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、第１デバイスと第３デバイスと間の第３通信と、第１通信とにおいて互いに異なる。
　本開示の一側面に係る通信システムは、第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと第２デバイスとの間の第２通信とを保護する保護部を備えている。保護部は、以下の（１）～（４）を実行する。
（１）第１セッション鍵を導出または受信すること
（２）第１セッション鍵を第１通信の暗号化もしくは復号とメッセージ認証とに使用すること
（３）第１セッション鍵によって保護された第１通信を使用して第２セッション鍵を受信すること
（４）第２セッション鍵を第２通信の暗号化、復号またはメッセージ認証に使用すること
ここで、第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、第１デバイスと第３デバイスと間の第３通信と、第１通信とにおいて互いに異なる。
本技術を適用した通信システムの第１の実施の形態の構成例を示すブロック図である。 本技術を適用した通信システムの第２の実施の形態の構成例を示すブロック図である。 D-PHY用の拡張パケットの全体的なパケット構造の第１の構造例を示す図である。 D-PHY用の拡張ショートパケットのパケット構造の第１の構造例を示す図である。 D-PHY用の拡張ロングパケットのパケット構造の第１の構造例を示す図である。 C-PHY用の拡張パケットの全体的なパケット構造の第１の構造例を示す図である。 C-PHY用の拡張ショートパケットのパケット構造の第１の構造例を示す図である。 C-PHY用の拡張ロングパケットのパケット構造の第１の構造例を示す図である。 イメージセンサの構成例を示すブロック図である。 アプリケーションプロセッサの構成例を示すブロック図である。 イメージセンサがパケットを送信する処理を説明するフローチャートである。 拡張モード送信処理を説明するフローチャートである。 アプリケーションプロセッサがパケットを受信する処理を説明するフローチャートである。 拡張モード受信処理を説明するフローチャートである。 D-PHY用の拡張パケットの全体的なパケット構造の第２の構造例を示す図である。 D-PHY用の拡張ロングパケットのパケット構造の第２の構造例を示す図である。 C-PHY用の拡張ショートパケットのパケット構造の第２の構造例を示す図である。 C-PHY用の拡張ロングパケットのパケット構造の第２の構造例を示す図である。 D-PHYおよびC-PHYを切り替える構成の変形例を示すブロック図である。 本技術を適用した通信システムの第３の実施の形態の構成例を示すブロック図である。 パケット改変禁止の規定に対応するD-PHY用の拡張パケットの構造例を示す図である。 パケット改変禁止の規定に対応するC-PHY用の拡張パケットの構造例を示す図である。 パケット改変禁止の規定に対応するA-PHY用の拡張パケットの構造例を示す図である。 パケット改変禁止の規定に適応したパケット送受信処理を説明するフローチャートである。 パケット改変禁止の規定に適応したイメージセンサの構成例を示すブロック図である。 パケット改変禁止の規定に適応したアプリケーションプロセッサの構成例を示すブロック図である。 イメージセンサおよびアプリケーションプロセッサが直結構成された通信システムの構成例を示すブロック図である。 アプリケーションプロセッサ側で生成されるリードコマンドのパケット構成の一例を示す図である。 A-PHY転送されるリードコマンドのパケット構成の一例を示す図である。 イメージセンサ側のリードコマンドおよびリードデータのパケット構成の一例を示す図である。 A-PHY転送されるリードデータのパケット構成の一例を示す図である。 アプリケーションプロセッサ側で取得したリードデータのパケット構成の一例を示す図である。 アプリケーションプロセッサ側で生成されるライトデータのパケット構成の一例を示す図である。 A-PHY転送されるライトデータのパケット構成の一例を示す図である。 イメージセンサ側で取得したライトデータのパケット構成の一例を示す図である。 拡張パケットヘッダePHおよび拡張パケットフッタePFの概要を説明する図である。 CCI-FSを使用した通信処理の初期設定および確認動作を説明するフローチャートである。 CCI-FSを使用したライト動作を説明するフローチャートである。 CCI-FSを使用したリード動作を説明するフローチャートである。 イメージセンサおよびアプリケーションプロセッサがSerDes接続構成された通信システムの構成例を示すブロック図である。 アプリケーションプロセッサ側で生成されるリードコマンドのパケット構成の一例を示す図である。 I2C/I3Cで出力されるリードコマンドのパケット構成の一例を示す図である。 A-PHY転送されるリードコマンドのパケット構成の一例を示す図である。 スレーブ側のSerDes装置で生成されるリードデータのパケット構成の一例を示す図である。 イメージセンサ側のリードコマンドおよびリードデータのパケット構成の一例を示す図である。 I2C/I3Cで出力されるリードデータのパケット構成の一例を示す図である。 A-PHY転送されるリードデータのパケット構成の一例を示す図である。 I2C/I3Cで出力されるリードデータのパケット構成の一例を示す図である。 アプリケーションプロセッサ側で取得したリードデータのパケット構成の一例を示す図である。 CCI-FSを使用した通信処理の初期設定および確認動作を説明するフローチャートである。 CCI-FSを使用したライト動作を説明するフローチャートである。 CCI-FSを使用したリード動作を説明するフローチャートである。 Sequence A_Write（AP時）処理を説明するフローチャートである。 Sequence A_Read_CMD（AP時）処理を説明するフローチャートである。 Sequence C（AP時）処理を説明するフローチャートである。 Sequence B（SerDes(Slave)時）処理を説明するフローチャートである。 Sequence A_Read_Data（AP時）処理を説明するフローチャートである。 拡張パケットヘッダePH0、拡張パケットヘッダePH1、および拡張パケットヘッダePH2の詳細を示す図である。 拡張パケットヘッダePH3の詳細を示す図である。 拡張パケットヘッダePHの拡張DTの詳細を示す図である。 従来のI2Cのハードウェアでの構成例を示すブロック図である。 I2Cバス上のデータ転送時の波形の一例を示す図である。 A-PHY直結構成の通信システムにおけるCCI関連の構成例を示すブロック図である。 ネットワークの接続形態の一例を示す図である。 CCI-FS処理部の回路構成の一例を示すブロック図である。 レジスタ構成例を示す図である。 Bridge構成時のレジスタ構成例を示す図である。 Error関連レジスタのレジスタ構成例を示す図である。 アプリケーションプロセッサ側で生成されるライトデータのパケット構成における拡張パケットヘッダePHの変形例を示す図である。 アプリケーションプロセッサ側で生成されるリードコマンドのパケット構成における拡張パケットヘッダePHの変形例を示す図である。 A-PHY直結構成におけるアプリケーションプロセッサとイメージセンサとの間のフローを説明する図である。 Clock Stretch方式を用いたフローを説明する図である。 CCI-FS処理部を備えるイメージセンサの詳細な構成例を示すブロック図である。 CCI-FS処理部を備えるアプリケーションプロセッサの詳細な構成例を示すブロック図である。 本技術を適用した通信システムの第４の実施の形態の構成例を示すブロック図である。 イメージセンサの詳細な構成例を示すブロック図である。 アプリケーションプロセッサの詳細な構成例を示すブロック図である。 通信処理の第１の処理例を説明するフローチャートである。 通信処理の第１の処理例を説明するフローチャートである。 通信処理の第１の処理例を説明するフローチャートである。 検証用パケットおよび被検証パケットについて説明する図である。 検証用パケットおよび被検証パケットについて説明する図である。 データ検証処理を説明するフローチャートである。 メッセージカウント値送信処理を説明するフローチャートである。 埋め込みデータについて説明する図である。 画像データのデータ構造の一例を示す図である。 画像データ送信処理を説明するフローチャートである。 完全性演算値送信処理を説明するフローチャートである。 画像データのデータ構造の第１の変形例を示す図である。 画像データのデータ構造の第２の変形例を示す図である。 画像データのデータ構造の第３の変形例を示す図である。 完全性演算値処理の第１の処理例を説明するフローチャートである。 完全性演算値処理の第２の処理例を説明するフローチャートである。 完全性演算値処理の第３の処理例を説明するフローチャートである。 完全性演算値処理の第４の処理例を説明するフローチャートである。 初期化ベクトルが格納される初期カウンタブロックの一例を示す図である。 GHASH関数を示す図である。 GCTR関数を示す図である。 GCM-AE関数を示す図である。 GCM-AD関数を示す図である。 ラインごとに完全性演算値MACを送信する画像データのデータ構造の一例を示す図である。 初期化ベクトルの一例を示す図である。 送信側から受信側へ初期化ベクトルを送信する一例を示す図である。 CSI-2またはCCIの拡張フォーマットの一例を示す図である。 ラインMAC方式の送信処理を説明するフローチャートである。 フレームごとに完全性演算値MACが配置された画像データのデータ構造の一例を示す図である。 初期化ベクトルの一例を示す図である。 送信側から受信側へ初期化ベクトルを送信する一例を示す図である。 フレームMAC方式の送信処理を説明するフローチャートである。 選択処理を説明するフローチャートである。 セキュリティMAC情報の一例を示す図である。 メッセージカウント値およびフレームカウント値のロールオーバー周期の一例を示す図である。 初期化ベクトルの構成について説明する図である。 データ検証処理を説明するフローチャートである。 反映処理を説明する図である。 セキュリティプロトコルの一例を示す図である。 Source IDまたはFinal Destination IDの一例を示す図である。 自らの異常の有無を診断するイメージセンサの詳細な構成例を示すブロック図である。 妨害検出部による妨害検出処理（その１）を説明するフローチャートである。 イメージセンサによりToF方式の測距センサを実現する際の発光パターン（受光パターン）を格納パターンとして格納する際の格納方法を説明する図である。 イメージセンサによりToF方式の測距センサを実現する際の発光パターン（受光パターン）を格納パターンとして格納する際の格納方法を説明する図である。 妨害検出部による妨害検出処理（その２）を説明するフローチャートである。 障害検出部による障害検出処理を説明するフローチャートである。 侵害検出部によるセキュリティ部の異常検出処理を説明するフローチャートである。 温度検出部による異常検出処理を説明するフローチャートである。 イメージセンサの異常の有無を検出するアプリケーションプロセッサの詳細な構成例を示すブロック図である。 アプリケーションプロセッサが、イメージセンサの異常の有無を検出する処理をするときのイメージセンサの処理を説明するフローチャートである。 アプリケーションプロセッサが、イメージセンサの異常の有無を検出する処理をするときのアプリケーションプロセッサの処理を説明するフローチャートである。 画像データの高速データ送信を阻害せずに特異メッセージの高速データ送信を実現する際の特異メッセージを格納する位置を説明するための画像データのデータ構造の一例を示す図である。 画像データの高速データ送信を阻害せずに、特異メッセージの高速データ送信が実行される場合の処理を説明するフローチャートである。 撮像送信処理（その１）を説明するフローチャートである。 撮像送信処理（その１）の応用例を説明するフローチャートである。 撮像送信処理（その２）を説明するフローチャートである。 イメージセンサによる撮像送信処理（その３）を説明するフローチャートである。 アプリケーションプロセッサによる撮像送信処理（その３）を説明するフローチャートである。 イメージセンサによる撮像送信処理（その４）を説明するフローチャートである。 アプリケーションプロセッサによる撮像送信処理（その４）を説明するフローチャートである。 イメージセンサによる撮像送信処理（その５）を説明するフローチャートである。 アプリケーションプロセッサによる撮像送信処理（その５）を説明するフローチャートである。 イメージセンサによる撮像送信処理（その６）を説明するフローチャートである。 アプリケーションプロセッサによる撮像送信処理（その６）を説明するフローチャートである。 イメージセンサによる撮像送信処理（その７）を説明するフローチャートである。 アプリケーションプロセッサによる撮像送信処理（その７）を説明するフローチャートである。 イメージセンサによる撮像送信処理（その８）を説明するフローチャートである。 アプリケーションプロセッサによる撮像送信処理（その８）を説明するフローチャートである。 撮像送信処理（その９）を説明するフローチャートである。 撮像送信処理（その１０）を説明するフローチャートである。 撮像送信処理（その１１）を説明するフローチャートである。 ハミング距離の異なる２種類のカウント値を用いたメッセージカウント値を説明する図である。 ２種類のカウント値を用いたメッセージカウント値の不具合や改竄の有無を検出する方法を説明する図である。 ２種類のカウント値を用いたメッセージカウント値の不具合や改竄の有無を検出する方法を説明する図である。 メッセージカウント処理を説明するフローチャートである。 拡張パケットヘッダePH2におけるリザーブド領域（Reserved）にWarning Descriptorが設定されるときの拡張パケットヘッダePH2の構成例を説明する図である。 Warning Descriptor（特異メッセージ）の各ビットを用いた識別情報の記述例を説明する図である。 拡張パケットヘッダに、第１特異メッセージとして警告速報（例えば、Physical attack detection）が設定されるときの構成例を説明する図である。 特異メッセージを分離して送信するときのイメージセンサの送信処理を説明するフローチャートである。 特異メッセージを分離して送信するときのアプリケーションプロセッサの送信処理を説明するフローチャートである。 警告速報が送信された後、警告詳細の読み出し命令を送信する場合の特異メッセージを分離して送信するときの送信処理を説明するフローチャートである。 イメージセンサ１２１１内外の異常の有無、イメージセンサ１２１１に対する妨害または攻撃の有無、などの何れかの特異メッセージが設定されるSecurity Descriptorの構成例を説明する図である。 イメージセンサとアプリケーションプロセッサとが実装された推進装置の構成例を示すブロック図である。 図１６０の推進装置の推進を制御する推進制御処理（その１）を説明する図である。 図１６０の推進装置の推進を制御する推進制御処理（その２）を説明する図である。 図１６０の推進装置の推進を制御するマイクロコンピュータによる推進制御処理（その３）を説明する図である。 図１６０の推進装置の推進を制御する撮像部による推進制御処理（その３）を説明する図である。 HEARTBEAT機能の有効化（HBEAT_CAP=1）または無効化（HBEAT_CAP=0）を設定するResponder flag fields definitionsの構成例を説明する図である。 HEARTBEAT要求メッセージの構成例を説明する図である。 HEARTBEAT_ACK応答メッセージの構成例を説明する図である。 HEARTBEAT_NAK応答メッセージの構成例を説明する図である。 END_SESSION要求メッセージの構成例を説明する図である。 HEARTBEAT処理（その１）を説明するフローチャートである。 END_SESSION_NAK応答メッセージの構成例を説明する図である。 CCIホスト（リクエスタ）のHEARTBEAT処理（その２）を説明するフローチャートである。 CCIデバイス（レスポンダ）のHEARTBEAT処理（その２）を説明するフローチャートである。 CCIホスト（リクエスタ）のHEARTBEAT処理（その３）を説明するフローチャートである。 CCIデバイス（レスポンダ）のHEARTBEAT処理（その３）を説明するフローチャートである。 ERROR応答メッセージの構成例を説明する図である。 Error codeとError dataの設定例を説明する図である。 ExtendedErrorDataの設定例を説明する図である。 疑似HEARTBEAT機能が用いられる場合のRegistry or standards body IDの設定例を説明する図である。 VENDOR_DEFINED_REQUEST要求メッセージの設定例を説明する図である。 VENDOR_DEFINED_RESPONSE応答メッセージの設定例を説明する図である。 SPDMの鍵スケジュールを説明する図である。 KEY_UPDATA_operationsの例を示す図である。 鍵更新に関する処理の流れの例を説明するフローチャートである。 ePH2の例を示す図である。 セッション鍵更新の流れの例を説明するフローチャートである。 プロセッサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 セッション鍵更新の流れの例を説明するフローチャートである。 プロセッサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 プロセッサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 KeyUpdataReqとKeySwitchTimingの例を示す図である。 セッション鍵更新の流れの例を説明するフローチャートである。 プロセッサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 プロセッサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 プロセッサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 プロセッサ処理の流れの例を説明するフローチャートである。 センサ処理の流れの例を説明するフローチャートである。 EvenOddkeyの例を示す図である。 セッション鍵の導出例を示す図である。 セッション鍵の導出例を示す図である。 本技術を適用した通信システムの第５の実施の形態の構成例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 イメージセンサおよびプロセッサの構成の一変形例を示すブロック図である。 制御系通信（Control Plane）におけるリプレイ攻撃対策の一例を示す図である。 初期化ベクトルの一例を示す図である。 Write messageの一例を示す図である。 Write messageの一例を示す図である。 制御系通信（Control Plane）におけるリプレイ攻撃対策の一例を示す図である。 VENDOR_DEFINED_REQUEST要求メッセージの設定例を説明する図である。 ライトデータのパケット構成の一例を示す図である。 VENDOR_DEFINED_REQUEST要求メッセージの設定例を説明する図である。 リードデータのパケット構成の一例を示す図である。 画像系通信（Data Plane）におけるリプレイ攻撃対策の一例を示す図である。 画像データのデータ構造の一例を示す図である。 図２２７の用語を説明する図である。 画像系通信（Data Plane）におけるリプレイ攻撃対策の一例を示す図である。 画像データのデータ構造の一例を示す図である。 画像系通信（Data Plane）におけるリプレイ攻撃対策の一例を示す図である。 画像データのデータ構造の一例を示す図である。 図２３２の用語を説明する図である。 SSMCにおけるセッション鍵の生成送信処理の一例を説明するフローチャートである。 図２３４に続く処理の一例を説明するフローチャートである。 SoCまたはBridge一端におけるセッション鍵の更新処理の一例を説明するフローチャートである。 SensorまたはBridge他端におけるセッション鍵の更新処理の一例を説明するフローチャートである。 SSMCにおけるセッション鍵の生成送信処理の一例を説明するフローチャートである。 図２３８に続く処理の一例を説明するフローチャートである。 SoCまたはBridge一端におけるセッション鍵の更新処理の一例を説明するフローチャートである。 SensorまたはBridge他端におけるセッション鍵の更新処理の一例を説明するフローチャートである。 図２０８の構成の一変形例を示すブロック図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータの処理の一例を示す図である。 機能レジスタの一例を示す図である。 機能レジスタの一例を示す図である。 リードデータのパケット構成の一例を示す図である。 リードデータの処理の一例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータの処理の一例を示す図である。 EXTENDED HEADERの設定例を示す図である。 ライトデータのパケット構成の一例を示す図である。 EXTENDED HEADERの設定例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータの処理の一例を示す図である。 第２CCIモードにおけるMACまたはCRCの演算処理の一例を説明するフローチャートである。 Register definitionおよびEXTENDED HEADERの設定例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータの処理の一例を示す図である。 第２CCIモードにおけるGCMまたはCCMの演算処理の一例を説明するフローチャートである。 Register definitionおよびEXTENDED HEADERの設定例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータの処理の一例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータの処理の一例を示す図である。 第１CCIモードにおけるGCMまたはCCMの演算処理の一例を説明するフローチャートである。 Capability registerの設定例を示す図である。 Vendor defined SPDM messageの設定例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータの処理の一例を示す図である。 内部処理順序の切り替えの一例を説明するフローチャートである。 Capability registerの設定例を示す図である。 Vendor defined SPDM messageの設定例を示す図である。 内部処理順序の切り替えの一例を説明するフローチャートである。 内部処理順序の切り替えの一例を説明するフローチャートである。 初期化ベクトルの通知処理の一例を説明するフローチャートである。 ライトデータのパケット構成の一例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータのパケット構成の一例を示す図である。 ライトデータのパケット構成の一例を示す図である。 Capability registerの設定例を示す図である。 Vendor defined SPDM messageの設定例を示す図である。 EXTENDED HEADERの設定例を示す図である。 メッセージ認証手順の一例を説明するフローチャートである。 メッセージ認証ポリシーの一例を示す図である。 メッセージ認証ポリシーの一例を示す図である。 メッセージ認証ポリシーの一例を示す図である。 Capability registerの設定例を示す図である。 Vendor defined SPDM messageの設定例を示す図である。 初期化ベクトルの一例を示す図である。 初期化ベクトルの一例を示す図である。 Mode in IVの一例を示す図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
　以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
　＜通信システムの構成例＞
　図１は、本技術を適用した通信システムの第１の実施の形態の構成例を示すブロック図である。
　図１に示すように、通信システム１１は、イメージセンサ２１およびアプリケーションプロセッサ２２がバス２３を介して接続されて構成される。例えば、通信システム１１は、いわゆるスマートフォンなどのような既存のモバイル機器の内部におけるCSI-2接続に用いられる。
　イメージセンサ２１は、例えば、レンズや撮像素子（いずれも図示せず）などとともに、拡張モード対応CSI-2送信回路３１が組み込まれて構成される。例えば、イメージセンサ２１は、撮像素子が撮像することで取得した画像の画像データを、拡張モード対応CSI-2送信回路３１によりアプリケーションプロセッサ２２へ送信する。
　アプリケーションプロセッサ２２は、LSI（Large Scale Integration）とともに、拡張モード対応CSI-2受信回路３２が組み込まれて構成される。このLSIは、通信システム１１を備えるモバイル機器で実行される各種のアプリケーションに応じた処理を行う。アプリケーションプロセッサ２２は、例えば、イメージセンサ２１から送信されてくる画像データを、拡張モード対応CSI-2受信回路３２により受信する。アプリケーションプロセッサ２２は、例えば、その画像データに対して、アプリケーションに応じた処理をLSIにより行う。
　バス２３は、CSI-2の規格に準拠して信号を伝送する通信経路である。バス２３では、例えば、信号を伝送することが可能な伝送距離は３０ｃｍ程度となっている。また、バス２３は、図示するように複数本の信号線（I2C，CLKP/N，D0P/N，D1P/N，D2P/N，D3P/N）によって、イメージセンサ２１およびアプリケーションプロセッサ２２を接続する。
　拡張モード対応CSI-2送信回路３１および拡張モード対応CSI-2受信回路３２は、CSI-2の規格を拡張させた拡張モードでの通信に対応しており、互いに信号の送信および受信を行うことができる。なお、拡張モード対応CSI-2送信回路３１および拡張モード対応CSI-2受信回路３２の詳細な構成については、図９および１０を参照して後述する。
　図２は、本技術を適用した通信システムの第２の実施の形態の構成例を示すブロック図である。
　図２に示すように、通信システム１１Ａでは、イメージセンサ２１およびSerDes装置２５がバス２４－１を介して接続される。通信システム１１Ａでは、アプリケーションプロセッサ２２およびSerDes装置２６がバス２４－２を介して接続されている。通信システム１１Ａでは、SerDes装置２５およびSerDes装置２６がバス２７を介して接続されている。例えば、通信システム１１Ａは、既存の車載カメラにおける接続に用いられる。
　ここで、イメージセンサ２１およびアプリケーションプロセッサ２２は、図１のイメージセンサ２１およびアプリケーションプロセッサ２２と同様に構成されており、その詳細な説明は省略する。
　バス２４－１および２４－２は、図１のバス２３と同様に、CSI-2の規格に準拠して信号を伝送する通信経路であり、図示するように複数本の信号線（HS-GPIO，I2C/I3C，CLKP/N，D0P/N，D1P/N，D2P/N，D3P/N）を備えて構成される。
　SerDes装置２５は、CSI-2受信回路３３およびSerDes（Serializer Deserializer）送信回路３４を備えて構成される。例えば、SerDes装置２５は、CSI-2受信回路３３が、拡張モード対応CSI-2送信回路３１との間で通常のCSI-2の規格に準拠した通信を行うことにより、イメージセンサ２１から送信されてくるビット並列の信号を取得する。そして、SerDes装置２５は、その取得した信号をビット直列に変換して、SerDes送信回路３４がSerDes受信回路３５との間で１レーンでの通信を行うことにより、その信号をSerDes装置２６へ送信する。
　SerDes装置２６は、SerDes受信回路３５およびCSI-2送信回路３６を備えて構成される。例えば、SerDes装置２６は、SerDes受信回路３５が、SerDes送信回路３４との間で１レーンでの通信を行うことにより送信されてくるビット直列の信号を取得する。そして、SerDes装置２６は、その取得した信号をビット並列に変換して、CSI-2送信回路３６が、拡張モード対応CSI-2受信回路３２との間で通常のCSI-2の規格に準拠した通信を行うことにより、アプリケーションプロセッサ２２へ送信する。
　バス２７は、A-PHYや、FPD(Flat Panel Display)-LINK IIIなどのような規格に準拠して信号を伝送する通信経路である。バス２７において、例えば、信号を伝送することが可能な伝送距離は１５ｍ程度の長距離となっている。
　これらの長距離伝送可能な物理層インタフェースによって、自動車業界が高度な運転支援システム（ADAS）、自動運転システム（ADS）、およびカメラや車載インフォテインメント（IVI）ディスプレイを含むその他のサラウンドセンサーアプリケーションを利用することが可能となる。MIPI A-PHYは、ポイントツーポイントトポロジの非対称データリンク層（非対称上位層）を有し、同一の物理配線を、高速データ伝送、制御データ、電力でシェアすることを可能としている。MIPI A-PHYは、カメラ、センサ、ディスプレイの統合を簡素化するように設計されたエンドツーエンドシステムの基盤として機能すると同時に、機能的な安全性とセキュリティも組み込むことも可能としている。
　このように構成される通信システム１１および１１Ａは、拡張モード対応CSI-2送信回路３１および拡張モード対応CSI-2受信回路３２により、後述するように拡張されたパケット構造のパケットでデータを送受信することができる。これにより、より多様な用途、例えば、後述するようなRAW24や、SmartROI（Region of Interest）、GLD（Graceful Link Degradation）などに対応することができる。
　＜パケット構造の第１の構造例＞
　図３乃至図８を参照して、拡張モード対応CSI-2送信回路３１および拡張モード対応CSI-2受信回路３２の間の通信で用いられるパケットのパケット構造の第１の構造例について説明する。
　図３には、物理層がD-PHYである場合にCSI-2の拡張モードで用いられるパケット（以下、D-PHY用の拡張パケットと称する）の全体的なパケット構造が示されている。
　図３に示すように、D-PHY用の拡張パケットは、パケットヘッダおよびパケットフッタが既存のCSI-2規格と同一のパケット構造となっている。例えば、パケットヘッダには、仮想チャネルの回線数を示すVC（VirtualChannel）、データの種類を示すデータタイプ（DataType）、ペイロードのデータ長を示すWC（Word Count）、VCX/ECCが格納される。また、パケットフッタには、CRC（Cyclic Redundancy Check）が格納される。
　ここで、既存のCSI-2規格では、パケットヘッダで送信されるデータタイプは、0x38～x3Fがリザーブと定義されている。そこで、D-PHY用の拡張パケットでは、既存ではリザーブとなっているデータタイプを利用して、受信側で拡張モードを識別するための設定情報が新たに定義される。
　例えば、データタイプとして、・DataType[5:3]=3’b111の場合、拡張モード・DataType[2]=Reserve（RES：将来の拡張のための予約）・DataType[1:0]=extension mode type（４つの拡張モードを用意）を定義する。
　即ち、既存のCSI-2規格ではリザーブと定義されているデータタイプの0x38～x3Fのうち、例えば、DataType[5:3]が拡張モード設定情報として定義され、DataType[1:0]が拡張タイプ設定情報として定義される。拡張モード設定情報は、拡張モードであるか否かを示し、例えば、DataType[5:3]が3’b111である場合には拡張モードであることを示す。また、拡張モードのタイプとして、拡張モード０、拡張モード１、拡張モード２、および拡張モード３の４つのタイプが用意されるとき、拡張タイプ設定情報は、それらのうちの、いずれのタイプであるかを示す。例えば、DataType[1:0]が2’b00である場合には、拡張モードのタイプが拡張モード０であることを示す。
　そして、拡張モード０（DataType[1:0]=2’b00）では、例えば、ペイロードが４つに分離されたパケット構造が定義される。即ち、拡張モード０におけるペイロードは、図３に示すように、拡張パケットヘッダ（ePH：extended Packet Header）、オプショナル拡張パケットヘッダ（OePH：Optional extended Packet Header）、レガシーペイロード（Legacy Payload）、および、オプショナル拡張パケットフッタ（OePF：Optional extended Packet Footer）に分離される。なお、拡張パケットヘッダは、繰り返し送信してもよい。
　拡張パケットヘッダは、既存のCSI-2規格のペイロードに相当する先頭に配置され、拡張モードでは必ず送信する必要がある。例えば、拡張パケットヘッダは、図示するように、SROIの識別フラグ、拡張VC（VirtualChannel）、拡張DataType、OePHの選択フラグ、およびOePFの選択フラグなどの設定情報で構成される。ここで、拡張VCにより、既存のCSI-2規格では４ビットであったVCが８ビットに拡張され、拡張DataTypeにより、既存のCSI-2規格では４ビットであったDataTypeが８ビットに拡張される。
　例えば、D-PHY用のパケットでは、既存のパケットヘッダのVCが既に４ビット存在しており、拡張パケットヘッダの拡張VCを４ビットと定義することにより、合計で８ビットとすることができる。具体的には、OePH[7:0] = {5’h00,RSID,XY_POS,MC}、OePF[3:0] = {3’h0,pCRC}と定義することができ、それぞれの用途に必要なパケット送信のON/OFFを制御することができる。
　オプショナル拡張パケットヘッダおよびオプショナル拡張パケットフッタは、用途に応じて選択的に伝送される。
　レガシーペイロードは、既存のCSI-2の規格と同一のペイロードに相当する。
　このように、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、およびオプショナル拡張パケットフッタを必要に応じて設定することで、様々な用途に対応したデータを送信することができるようになる。また、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、およびオプショナル拡張パケットフッタで伝送されるデータは、26bit+6bitのECC（Error Correction Code）とする。これにより、既存のパケットヘッダの回路を流用して回路規模の増大を抑制し、かつ、エラー耐性の向上を図ることができる。
　このようなD-PHY用の拡張パケットの具体的な適用例として、図４には、物理層がD-PHYである場合にCSI-2の拡張モードで用いられるショートパケット（以下、D-PHY用の拡張ショートパケットと称する）のパケット構造が示されている。同様に、図５には、物理層がD-PHYである場合にCSI-2の拡張モードで用いられるロングパケット（以下、D-PHY用の拡張ロングパケットと称する）のパケット構造が示されている。
　図４に示すようなD-PHY用の拡張ショートパケットにおいて、パケットヘッダに格納されているデータタイプの拡張タイプ設定情報は、拡張モードのタイプが拡張モード０であること（DT[5:0]=0x1C(5’b111_0_0)）を示している。また、拡張パケットヘッダに格納されているデータタイプのショートパケット設定情報は、ショートパケットであること（DT[7:0]=0x00 (Frame Start Code（Short Packet）)）を示している。
　このように、拡張モードであり、かつ、拡張パケットヘッダに格納されているデータタイプがDT[7:0]=0x00～0x0Fである場合、拡張ショートパケットとし、オプショナル拡張パケットヘッダには必ず、拡張ショートパケットのShort Packet Data Fieldを含むデータが伝送される。このShort Packet Data Fieldは、既存のCSI-2の規格で定義されたものと同一である。
　なお、拡張ショートパケットの送信時には、オプショナル拡張パケットヘッダのうち、MC（GLD用MessageCount）とRSID（車載用行番号とSourceID）は送信しても良いが、レガシーペイロードとpCRCは不要であるため、送信禁止である。仮に、それらを誤って送信した場合には、受信側で無視される。
　そして、図４に示すようなパケット構造の拡張ショートパケットは、既存のCSI-2の規格に従った拡張ショートパケットと比較して、データタイプおよび仮想チャネルのビット幅を拡張することができ、オプショナル拡張パケットヘッダで定義される様々な用途に対応することができる。また、これらの機能が必要でない場合は、既存のCSI-2の規格に従った拡張ショートパケットを、拡張ロングパケットと一緒に送信するようにしてもよい。
　図５に示すようなD-PHY用の拡張ロングパケットにおいて、パケットヘッダに格納されているデータタイプの拡張タイプ設定情報は、拡張モードのタイプが拡張モード０であること（DT[5:0]=0x1C(5’b111_0_0)）を示している。また、拡張パケットヘッダに格納されているデータタイプのショートパケット設定情報は、ショートパケット以外であること（DT[7:0]は0x00～0x0F以外（＝拡張LongPackt））を示している。従って、拡張ロングパケットでは、Short Packet Data Fieldを含むデータは送信されない。
　また、拡張パケットヘッダの設定に従い、オプショナル拡張パケットヘッダ、レガシーペイロード、およびオプショナル拡張パケットフッタが、既存のCSI-2の規格でのペイロードに格納して伝送される。このように、既存のペイロードに格納して伝送されるため、既存のSerDes送信回路３４およびSerDes受信回路３５（図２）には、既存のペイロードで伝送される画像データと同様に認識され、そのまま後段に伝送される。
　そして、最後段のアプリケーションプロセッサ２２は、パケットヘッダのデータタイプDT[5:0]によって、拡張モードと判定することができる。従って、アプリケーションプロセッサ２２は、ペイロードの中身を、拡張パケットヘッダから順に解釈し、所望の拡張モードのデータを取り出すことができる。
　図６には、物理層がC-PHYである場合にCSI-2の拡張モードで用いられるパケット（以下、C-PHY用の拡張パケットと称する）の全体的なパケット構造が示されている。なお、図６に示すC-PHY用の拡張パケットにおいて、図３のD-PHY用の拡張パケットと共通する構成については説明を省略し、異なる構成について説明を行う。
　例えば、C-PHY用の拡張パケットでは、図３のD-PHY用の拡張パケットと同様に、データタイプで拡張モードを識別し、アプリケーションプロセッサ２２で実行される各アプリケーションに応じたデータは、すべてペイロードに埋め込まれて伝送される。
　図６に示すように、C-PHY用の拡張パケットは、既存のCSI-2規格に従ったC-PHY用のパケットと同様に、パケットヘッダを２回伝送し、C-PHYが16bitを7symbolに変換する都合上、16bit単位でデータを並べる。また、ペイロードの先頭には拡張パケットヘッダが配置されるが、仮想チャネルに関しては、C-PHYの場合、既存のパケットヘッダの先頭がその為にReserveとなっていたため、拡張パケットヘッダには仮想チャネルは格納されない。もちろん、D-PHY用の拡張パケットと同様に、拡張パケットヘッダに仮想チャネルを格納してもよい。
　また、オプショナル拡張パケットヘッダおよびオプショナル拡張パケットフッタはビット数が多いため、OePHFというフラグを準備し、このフラグが１の場合、OePH/OePF情報が次に伝送される。そして、ePH情報およびOePH情報の後、拡張パケットヘッダとしてCRCを伝送し、同様に構成されるパケットヘッダを２回繰り返して伝送する。このように、既存のパケットヘッダが２回伝送される仕組みと構造を同じにすることで、回路再利用性およびエラー耐性を両立することができる。
　このようなC-PHY用の拡張パケットの具体的な適用例として、図７には、物理層がC-PHYである場合にCSI-2の拡張モードで用いられるショートパケット（以下、C-PHY用の拡張ショートパケットと称する）のパケット構造が示されている。同様に、図８には、物理層がC-PHYである場合にCSI-2の拡張モードで用いられるロングパケット（以下、C-PHY用の拡張ロングパケットと称する）のパケット構造が示されている。
　なお、図７に示すC-PHY用の拡張ショートパケットは、図４に示したD-PHY用の拡張ショートパケットとパケット構造に大きな差異はなく、図８に示すC-PHY用の拡張ロングパケットは、図５に示したD-PHY用の拡張ロングパケットとパケット構造に大きな差異はない。
　＜イメージセンサおよびアプリケーションプロセッサの構成例＞
　（イメージセンサの構成例）
　図９は、拡張モード対応CSI-2送信回路３１を備えるイメージセンサ２１の構成例を示すブロック図である。
　図９に示すように、イメージセンサ２１は、拡張モード対応CSI-2送信回路３１の他に、画素４１、AD変換器４２、画像処理部４３、画素CRC演算部４４、物理層処理部４５、I2C/I3Cスレーブ４６、およびレジスタ４７を備えて構成される。また、拡張モード対応CSI-2送信回路３１は、パッキング部５１、パケットヘッダ生成部５２、拡張パケットヘッダ生成部５３、拡張パケットフッタ生成部５４、選択部５５および５６、CRC演算部５７、レーン分配部５８、CCIスレーブ５９、並びに、コントローラ６０を備えて構成される。
　画素４１は、受光した光の光量に応じたアナログの画素信号を出力し、AD変換器（ADC：Analog-to-Digital Converter）４２は、画素４１から出力される画素信号をデジタル変換して画像処理部４３に供給する。画像処理部（ISP：Image Signal Processor）４３は、画素信号に基づく画像に対する各種の画像処理を施して得られる画像データを画素CRC演算部４４およびパッキング部５１に供給する。また、画像処理部４３は、画像データが有効であるか否かを示すデータイネーブル信号data_enをパッキング部５１およびコントローラ６０に供給する。
　画素CRC演算部４４は、画像処理部４３から供給される画像データにおける画素ごとのCRCを演算して求め、そのCRCを拡張パケットフッタ生成部５４に供給する。
　物理層処理部４５は、C-PHYおよびD-PHYの両方の物理層処理を実行することができる。例えば、物理層処理部４５は、コントローラ６０から供給されるＣ層イネーブル信号cphy_enが有効である場合にはC-PHYの物理層処理を実行し、Ｃ層イネーブル信号cphy_enが無効である場合にはD-PHYの物理層処理を実行する。そして、物理層処理部４５は、レーン分配部５８により４レーンに分割されたパケットを、アプリケーションプロセッサ２２へ送信する。
　I2C/I3Cスレーブ４６は、I2C（Inter-Integrated Circuit）またはI3C（Improved Inter Integrated Circuits）の規格に基づき、アプリケーションプロセッサ２２のI2C/I3Cマスタ７２（図１０）による主導に従って通信を行う。
　レジスタ４７には、アプリケーションプロセッサ２２から送信されてくる各種の設定が、I2C/I3Cスレーブ４６およびCCIスレーブ５９を介して書き込まれる。ここで、レジスタ４７に書き込まれる設定としては、例えば、CSI-2規格に従った通信設定や、拡張モードの使用の有無を示す拡張モード設定、拡張モードでの通信で必要となる固定の通信設定などがある。
　パッキング部５１は、画像処理部４３から供給される画像データを、パケットのペイロードに格納するパッキング処理を行い、そのペイロードを選択部５５およびレーン分配部５８に供給する。
　パケットヘッダ生成部５２は、コントローラ６０から供給されるパケットヘッダ生成指示信号ph_goに従って、パケットヘッダの生成が指示されると、パケットヘッダを生成して選択部５５およびレーン分配部５８に供給する。
　即ち、パケットヘッダ生成部５２は、パケットで伝送されるデータについて設定された条件を示す設定情報、例えば、データのタイプを示すデータタイプを格納するパケットヘッダを、既存のCSI-2規格に従って生成する。また、パケットヘッダ生成部５２は、パケットで伝送されるデータのタイプを示す設定情報であるデータタイプにおいて、既存のCSI-2規格では未使用と定義されている未使用領域に、拡張ヘッダを使用する拡張モードであるか否かを示す拡張モード設定情報を格納する。さらに、パケットヘッダ生成部５２は、未使用領域に、拡張モードとして用意される複数のタイプの拡張モードのうちの、いずれのタイプであるかを示す拡張タイプ設定情報を格納する。
　拡張パケットヘッダ生成部５３は、コントローラ６０から供給される拡張パケットヘッダ生成指示信号eph_goおよび拡張パケットヘッダイネーブル信号ePH_enに従って、拡張パケットヘッダおよびオプショナル拡張パケットヘッダそれぞれを生成し、選択部５６およびレーン分配部５８に供給する。また、拡張パケットヘッダ生成部５３には、イメージセンサ２１の用途に応じて、車載用行番号やソースID（identification）などが供給され、必要に応じて、それらが拡張パケットヘッダまたはオプショナル拡張パケットヘッダに格納される。
　即ち、拡張パケットヘッダ生成部５３は、パケットヘッダ生成部５２により生成されるパケットヘッダとは別に、例えば、図３に示したような設定情報を格納する拡張パケットヘッダを生成する。さらに、拡張パケットヘッダ生成部５３は、オプショナル拡張パケットヘッダを送信する場合、オプショナル拡張パケットヘッダを送信するか否かを示すオプショナル拡張パケットヘッダ設定情報（OePH[7:0]）として、オプショナル拡張パケットヘッダを送信することを示すオプショナル拡張パケットヘッダ設定情報を拡張パケットヘッダに格納し、拡張パケットヘッダに続けてオプショナル拡張パケットヘッダを生成する。
　拡張パケットフッタ生成部５４は、コントローラ６０から供給される拡張パケットフッタ生成指示信号epf_goおよび拡張パケットヘッダイネーブル信号ePF_enに従って、オプショナル拡張パケットフッタを生成し、選択部５６およびレーン分配部５８に供給する。
　即ち、拡張パケットフッタ生成部５４は、拡張モードにおいて伝送されるパケットが、既存のCSI-2規格においてペイロードとして伝送されるデータを格納する拡張ロングパケットである場合に、データが格納されるレガシーペイロードに続けて配置されるオプショナル拡張パケットフッタを生成する。
　また、パケットヘッダ生成部５２、拡張パケットヘッダ生成部５３、および拡張パケットフッタ生成部５４には、コントローラ６０からＣ層イネーブル信号cphy_enが供給される。そして、Ｃ層イネーブル信号cphy_enが有効を示している場合、パケットヘッダ生成部５２はC-PHY用のパケットヘッダを生成し、拡張パケットヘッダ生成部５３はC-PHY用の拡張パケットヘッダおよびオプショナル拡張パケットヘッダを生成し、拡張パケットフッタ生成部５４はC-PHY用のオプショナル拡張パケットフッタを生成する。一方、Ｃ層イネーブル信号cphy_enが無効を示している場合、パケットヘッダ生成部５２はD-PHY用のパケットヘッダを生成し、拡張パケットヘッダ生成部５３はD-PHY用の拡張パケットヘッダおよびオプショナル拡張パケットヘッダを生成し、拡張パケットフッタ生成部５４はD-PHY用のオプショナル拡張パケットフッタを生成する。
　選択部５５は、コントローラ６０から供給されるＣ層イネーブル信号cphy_enに従って、Ｃ層イネーブル信号cphy_enが有効である場合、パケットヘッダ生成部５２から供給されるパケットヘッダを選択し、選択部５６へ供給する。一方、選択部５５は、Ｃ層イネーブル信号cphy_enが無効である場合、パッキング部５１から供給されるペイロードを選択し、選択部５６へ供給する。
　選択部５６は、コントローラ６０から供給されるデータ選択信号data_selに従って、選択部５５を介して選択的に供給されるパケットヘッダまたはペイロード、拡張パケットヘッダ生成部５３から供給される拡張パケットヘッダおよびオプショナル拡張パケットヘッダ、拡張パケットフッタ生成部５４から供給されるオプショナル拡張パケットフッタのうち、いずれかを選択してCRC演算部５７に供給する。
　CRC演算部５７は、選択部５６を介して選択的に供給されるパケットヘッダ、ペイロード、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、またはオプショナル拡張パケットフッタのCRCを演算して求め、そのCRCをレーン分配部５８に供給する。
　レーン分配部５８は、コントローラ６０の制御に従って、パッキング部５１から供給されるペイロード、パケットヘッダ生成部５２から供給されるパケットヘッダ、拡張パケットヘッダ生成部５３から供給される拡張パケットヘッダおよびオプショナル拡張パケットヘッダ、拡張パケットフッタ生成部５４から供給されるオプショナル拡張パケットフッタ、並びに、CRC演算部５７から供給されるCRCを、CSI-2の規格に従った４レーンに分配して、物理層処理部４５に供給する。
　CCI（Camera Control Interface）スレーブ５９は、CSI-2の規格に基づき、アプリケーションプロセッサ２２のCCIマスタ８８（図１０）による主導に従って通信を行う。
　コントローラ６０は、レジスタ４７に記憶されている各種の設定を読み出して、それらの設定に従って、拡張モード対応CSI-2送信回路３１を構成する各ブロックに対する制御を行う。例えば、コントローラ６０は、送信対象のデータの内容に応じて、既存のCSI-2規格に従ったパケット構造のパケットの送信と、拡張モード時におけるパケット構造のパケットの送信との切り替えを制御する。
　このようにイメージセンサ２１は構成されており、図３乃至図８を参照して説明したようなパケット構造の拡張パケットを生成して、アプリケーションプロセッサ２２へ送信することができる。
　（アプリケーションプロセッサの構成例）
　図１０は、拡張モード対応CSI-2受信回路３２を備えるアプリケーションプロセッサ２２の構成例を示すブロック図である。
　図１０に示すように、アプリケーションプロセッサ２２は、拡張モード対応CSI-2受信回路３２の他に、物理層処理部７１、I2C/I3Cマスタ７２、レジスタ７３、およびコントローラ７４を備えて構成される。また、拡張モード対応CSI-2受信回路３２は、パケットヘッダ検出部８１、レーン併合部８２、解釈部８３、選択部８４および８５、CRC演算部８６、アンパッキング部８７、並びに、CCIマスタ８８を備えて構成される。
　物理層処理部７１は、C-PHYおよびD-PHYの両方の物理層処理を実行することができる。上述したように、イメージセンサ２１の物理層処理部４５では、C-PHYおよびD-PHYのうちの、いずれか一方の物理層処理が行われ、物理層処理部７１は、物理層処理部４５において実行されたのと同一の物理層処理を実行する。
　I2C/I3Cマスタ７２は、I2CまたはI3Cの規格に基づき、イメージセンサ２１のI2C/I3Cスレーブ４６（図９）との通信を主導して行う。
　レジスタ７３には、コントローラ７４により、イメージセンサ２１のレジスタ４７に書き込むべき各種の設定が記録される。
　コントローラ７４は、アプリケーションプロセッサ２２を構成する各ブロックに対する制御を行う。
　パケットヘッダ検出部８１は、物理層処理部７１から供給されるパケットからパケットヘッダを検出し、パケットヘッダに格納されているデータタイプを確認する。そして、パケットヘッダ検出部８１は、パケットヘッダのデータタイプにおいて、拡張モード設定情報が拡張モードであることを示す場合（DataType[5:3]=3’b111）、拡張モードを示す拡張モード検出フラグを、解釈部８３、選択部８４、および選択部８５に供給する。また、パケットヘッダ検出部８１は、パケットヘッダに基づいて、分割されている４レーンの併合を有効とするか否かを示す併合イネーブル信号mrg_enをレーン併合部８２に供給する。
　即ち、パケットヘッダ検出部８１は、既存のCSI-2規格に従って、パケットで伝送されるデータについて設定された条件を示す設定情報（データタイプなど）が格納されるパケットヘッダを検出する。このとき、パケットヘッダ検出部８１は、パケットで伝送されるデータのタイプを示す設定情報であるデータタイプにおいて、既存のCSI-2規格では未使用と定義されている未使用領域に格納されている、拡張ヘッダを使用する拡張モードであるか否かを示す拡張モード設定情報に従って、拡張モード検出フラグを出力することで、既存のCSI-2規格に従ったパケット構造のパケットの受信と、拡張モード時におけるパケット構造のパケットの受信との切り替えを行わせる。また、パケットヘッダ検出部８１は、既存のCSI-2規格では未使用と定義されているデータタイプの未使用領域に格納されている拡張モードタイプ情報に従って、拡張モードとして用意される複数のタイプの拡張モードのうちの、いずれのタイプの拡張モードであるかを認識する。
　レーン併合部８２は、パケットヘッダ検出部８１から供給される併合イネーブル信号mrg_enが有効である場合、物理層処理部７１から供給される４レーンに分割されたパケットを併合する。そして、レーン併合部８２は、１レーンのパケットを解釈部８３、選択部８４、および選択部８５に供給する。
　解釈部８３は、パケットヘッダ検出部８１から供給される拡張モード検出フラグが、拡張モードであることを示している場合、拡張モードのパケット構造に基づいて、レーン併合部８２から供給されるパケットから、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、およびオプショナル拡張パケットフッタを読み出す。そして、解釈部８３は、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、およびオプショナル拡張パケットフッタに格納されている設定情報を解釈する。
　即ち、解釈部８３は、拡張ヘッダとして、既存のCSI-2規格に従ったペイロードの先頭に配置される拡張パケットヘッダを受信し、拡張パケットヘッダに格納されている設定情報を解釈する。また、解釈部８３は、拡張パケットヘッダに格納されているオプショナル拡張パケットヘッダ設定情報が、用途に応じて選択的に伝送されるオプショナル拡張パケットヘッダを送信することを示している場合、拡張パケットヘッダに続けてオプショナル拡張パケットヘッダを受信し、オプショナル拡張パケットヘッダに格納されている設定情報を解釈する。さらに、解釈部８３は、拡張モードにおいて伝送されるパケットが、既存のCSI-2規格においてペイロードとして伝送されるデータを格納する拡張ロングパケットである場合に、データが格納されるレガシーペイロードに続けて配置されるオプショナル拡張パケットフッタを受信し、オプショナル拡張パケットフッタを解釈する。
　そして、解釈部８３は、例えば、オプショナル拡張パケットヘッダに格納されている車載用行番号やソースIDなどを読み出して、後段のLSI（図示せず）へ出力する。
　なお、解釈部８３は、パケットヘッダ検出部８１から供給される拡張モード検出フラグが、拡張モードであることを示していない場合には、即ち、既存のパケット構造のパケットが供給されている場合には、上述したような処理を行わずに停止する。
　選択部８４は、パケットヘッダ検出部８１から供給される拡張モード検出フラグに従い、既存パケットのパケット構造または拡張パケットのパケット構造に基づいて、選択的に、アンパッキング部８７へデータを供給する。
　選択部８５は、パケットヘッダ検出部８１から供給される拡張モード検出フラグに従い、既存パケットのパケット構造または拡張パケットのパケット構造に基づいて、選択的に、CRC演算部８６へデータを供給する。
　CRC演算部８６は、選択部８５を介して選択的に供給されるパケットヘッダ、ペイロード、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、またはオプショナル拡張パケットフッタのCRCを演算する。そして、CRC演算部８６は、CRCエラーが検出された場合、その旨を示すcrcCRCエラー検出信号を後段のLSI（図示せず）へ出力する。
　アンパッキング部８７は、選択部８４を介して選択的に供給されるペイロードに格納されている画像データを取り出すアンパッキング処理を行い、取得した画像データを後段のLSI（図示せず）へ出力する。
　CCIマスタ８８は、CSI-2の規格に基づき、イメージセンサ２１のCCIスレーブ５９（図９）との通信を主導して行う。
　このようにアプリケーションプロセッサ２２は構成されており、イメージセンサ２１から送信されてくる拡張パケットを受信して、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、およびオプショナル拡張パケットフッタに格納されている設定情報を解釈して、画像データを取得することができる。
　＜通信処理＞
　図１１乃至図１４を参照して、イメージセンサ２１およびアプリケーションプロセッサ２２で行われる通信処理について説明する。
　図１１は、イメージセンサ２１がパケットを送信する処理を説明するフローチャートである。
　例えば、バス２３を介して、イメージセンサ２１がアプリケーションプロセッサ２２に接続されると処理が開始される。ステップＳ１１において、コントローラ６０は、アプリケーションプロセッサ２２と通信を開始するにあたって、拡張モードを使用するか否かを判定する。例えば、コントローラ６０は、レジスタ４７に記憶されている拡張モード設定を確認し、拡張モードを使用することを示す拡張モード設定がアプリケーションプロセッサ２２により書き込まれている場合、拡張モードを使用すると判定する。
　ステップＳ１１において、コントローラ６０が、拡張モードを使用しないと判定した場合、処理はステップＳ１２に進む。
　ステップＳ１２において、I2C/I3Cスレーブ４６は、アプリケーションプロセッサ２２から（後述する図１３のステップＳ５４で）送信されてくる画像データの送信開始命令を受信する。さらに、I2C/I3Cスレーブ４６は、その送信開始命令とともに送信されてくるCSI-2規格に従った通信設定を受信して、CCIスレーブ５９を介してレジスタ４７に書き込む。
　ステップＳ１３において、イメージセンサ２１では、レジスタ４７に記憶されている通信設定に基づいて、既存のCSI-2規格に従ったパケット構造のパケットをアプリケーションプロセッサ２２へ送信する、従来のパケット送信処理が実行される。
　一方、ステップＳ１１において、コントローラ６０が、拡張モードを使用すると判定した場合、処理はステップＳ１４に進む。
　ステップＳ１４において、I2C/I3Cスレーブ４６は、拡張モードでの通信で必要となる固定の通信設定（例えば、GLD時のPH/PFのレーンごとのコピーなど）を受信して、CCIスレーブ５９を介してレジスタ４７に書き込む。
　ステップＳ１５において、I2C/I3Cスレーブ４６は、アプリケーションプロセッサ２２から（後述する図１３のステップＳ５７で）送信されてくる画像データの送信開始命令を受信する。さらに、I2C/I3Cスレーブ４６は、その送信開始命令とともに送信されてくるCSI-2規格に従った通信設定を受信して、CCIスレーブ５９を介してレジスタ４７に書き込む。
　ステップＳ１６において、コントローラ６０は、パケットの送信を開始するか否かを判定し、パケットの送信を開始すると判定するまで処理を待機する。
　そして、ステップＳ１６において、パケットの送信を開始すると判定された場合、処理はステップＳ１７に進み、コントローラ６０は、拡張モードで送信すべきデータであるか否かを判定する。ここで、コントローラ６０は、送信対象のデータの内容に応じて、例えば、後述するような適用例のユースケースで送信されるようなデータである場合、拡張モードで送信すべきデータであると判定する。
　ステップＳ１７において、コントローラ６０が、拡張モードで送信すべきデータであると判定した場合、処理はステップＳ１８に進み、拡張モードに対応した拡張パケットを送信する拡張モード送信処理（図１２参照）が行われる。
　一方、ステップＳ１７において、コントローラ６０が、拡張モードで送信すべきデータでないと判定した場合、処理はステップＳ１９に進む。
　ステップＳ１９において、コントローラ６０は、ショートパケットを送信するか否かを判定する。例えば、コントローラ６０は、フレーム開始時およびフレーム終了時にショートパケットを送信すると判定する。
　ステップＳ１９において、コントローラ６０がショートパケットを送信すると判定した場合、処理はステップＳ２０に進む。ステップＳ２０において、パケットヘッダ生成部５２がパケットヘッダを生成して、従来のパケット構造のショートパケットをアプリケーションプロセッサ２２へ送信する。
　一方、ステップＳ１９において、コントローラ６０がショートパケットを送信しない（即ち、ロングパケットを送信する）と判定した場合、処理はステップＳ２１に進む。ステップＳ２１において、パッキング部５１が画像データをペイロードに格納し、CRC演算部５７がCRCを求めることにより、従来のパケット構造のロングパケットを生成して、アプリケーションプロセッサ２２へ送信する。
　ステップＳ１８、ステップＳ２０、またはステップＳ２１の処理後、処理はステップＳ２２に進み、コントローラ６０は、パケット送信処理を終了する。その後、処理はステップＳ１６に戻り、以下、次のパケットを対象として、同様にパケットを送信する処理が繰り返して行われる。
　図１２は、図１１のステップＳ１８の処理で行われる拡張モード送信処理を説明するフローチャートである。
　ステップＳ３１において、パケットヘッダ生成部５２は、VCやデータタイプ、WCなどを格納したパケットヘッダを生成し、アプリケーションプロセッサ２２へ送信する。このとき、パケットヘッダ生成部５２は、パケットヘッダのデータタイプに、拡張モードであることを示す拡張モード設定情報（DataType[5:3]=3’b111）、および、拡張モードのモード設定が拡張モード０であることを識別する拡張タイプ設定情報（DataType[1:0] =2’b00）を書き込む。
　ステップＳ３２において、アプリケーションプロセッサ２２は、拡張ショートパケットを送信するか否かを判定する。例えば、コントローラ６０は、フレーム開始時およびフレーム終了時に拡張ショートパケットを送信すると判定する。
　ステップＳ３２において、アプリケーションプロセッサ２２が、拡張ショートパケットを送信すると判定した場合、処理はステップＳ３３に進む。
　ステップＳ３３において、拡張パケットヘッダ生成部５３は、ペイロードの１バイト目で、データタイプ（DataType[7:0]）をショートパケットと設定した拡張パケットヘッダを送信する。このとき、拡張パケットヘッダ生成部５３は、拡張パケットヘッダに格納される各種の設定（例えば、OePH[7:0]やOePF[3:0]など）を行う。
　ステップＳ３４において、拡張パケットヘッダ生成部５３は、ペイロードの２バイト目に、フレームナンバー（FN：FrameNumber）を格納して送信する。
　ステップＳ３５において、拡張パケットヘッダ生成部５３は、ステップＳ３３で行われた設定（OePH[7:0]）に従って、図４に示したようなオプショナル拡張パケットヘッダを生成して送信する。
　ステップＳ３６において、CRC演算部５７は、CRCを求めて、パケットフッタとして送信する。
　一方、ステップＳ３２において、アプリケーションプロセッサ２２が、拡張ショートパケットを送信しない（即ち、ロングパケットを送信する）と判定した場合、処理はステップＳ３７に進む。
　ステップＳ３７において、拡張パケットヘッダ生成部５３は、ペイロードの１バイト目で、データタイプ（DataType[7:0]）をショートパケット以外と設定した拡張パケットヘッダを送信する。このとき、拡張パケットヘッダ生成部５３は、拡張パケットヘッダに格納される各種の設定（例えば、OePH[7:0]やOePF[3:0]など）を行う。
　ステップＳ３８において、拡張パケットヘッダ生成部５３は、ステップＳ３７で行われた設定（OePH[7:0]）に従って、図５に示したようなオプショナル拡張パケットヘッダを生成して送信する。
　ステップＳ３９において、パッキング部５１は、画像処理部４３から供給される画像データをパッキングし、レガシーペイロードを生成して送信する。
　ステップＳ４０において、拡張パケットフッタ生成部５４は、ステップＳ３７で行われた設定（OePF[3:0]）に従って、図４に示したようなオプショナル拡張パケットフッタを生成して送信する。
　ステップＳ４１において、CRC演算部５７は、CRCを求めて、パケットフッタとして送信する。
　そして、ステップＳ３６またはＳ４１の処理後、拡張モード送信処理は終了される。
　以上のように、イメージセンサ２１は、拡張ショートパケットまたは拡張ロングパケットを生成して送信することができる。
　図１３は、アプリケーションプロセッサ２２がパケットを受信する処理を説明するフローチャートである。
　例えば、バス２３を介して、イメージセンサ２１がアプリケーションプロセッサ２２に接続されると処理が開始される。ステップＳ５１において、コントローラ７４は、イメージセンサ２１の初期設定（例えば、物理層としてC-PHYおよびD-PHYのどちらを使用するかなど）をレジスタ７３に書き込み、CCIマスタ８８を介してI2C/I3Cマスタ７２によりイメージセンサ２１へ送信する。これにより、その初期設定が、イメージセンサ２１のレジスタ４７に書き込まれる。
　ステップＳ５２において、コントローラ７４は、イメージセンサ２１が拡張モードに対応しているか否かを認識する。例えば、コントローラ７４は、I2C/I3Cマスタ７２によりイメージセンサ２１のレジスタ４７に記憶されている設定値（例えば、拡張PH/PF対応capability）を取得することで、イメージセンサ２１が拡張モードに対応しているか否かを認識することができる。または、コントローラ７４は、例えば、マニュアルなどによる入力に基づいて、事前に、イメージセンサ２１が拡張モードに対応しているか否かを認識することができる。
　ステップＳ５３において、コントローラ７４は、イメージセンサ２１が拡張モードに対応しており、かつ、アプリケーションプロセッサ２２が実行するアプリケーションによって拡張モードの使用が求められているか否かを判定する。
　ステップＳ５３において、コントローラ７４が、イメージセンサ２１が拡張モードに対応していない、または、拡張モードの使用が求められていないと判定した場合、処理はステップＳ５４に進む。
　ステップＳ５４において、コントローラ７４は、I2C/I3Cマスタ７２により画像データの送信開始命令をイメージセンサ２１へ送信する。このとき、コントローラ７４は、CSI-2規格に従った通信設定も送信させる。
　ステップＳ５５において、アプリケーションプロセッサ２２では、ステップＳ５４で送信した通信設定に基づいて、既存のCSI-2規格に従ったパケット構造のパケットを受信する、従来のパケット受信処理が行われる。
　一方、ステップＳ５３において、コントローラ７４が、イメージセンサ２１が拡張モードに対応しており、かつ、アプリケーションプロセッサ２２が実行するアプリケーションによって拡張モードの使用が求められていると判定した場合、処理はステップＳ５６に進む。
　ステップＳ５６において、I2C/I3Cマスタ７２は、拡張モードでの通信が開始される前に、拡張モードでの通信に必要となる固定の通信設定を送信する。これにより、その固定の通信設定が、イメージセンサ２１のレジスタ４７に書き込まれる（図１１のステップＳ１４）。
　ステップＳ５７において、コントローラ７４は、I2C/I3Cマスタ７２により画像データの送信開始命令をイメージセンサ２１へ送信する。このとき、コントローラ７４は、CSI-2規格に従った通信設定も送信させる。
　ステップＳ５８において、パケットヘッダ検出部８１は、物理層処理部７１から供給されるデータを確認することによりパケットの受信を開始したか否かを判定し、パケットの受信を開始したと判定するまで処理を待機する。例えば、パケットヘッダ検出部８１は、物理層処理部７１から供給されるデータからパケットヘッダを検出した場合、パケットの受信を開始したと判定する。
　ステップＳ５８において、パケットヘッダ検出部８１が、パケットの受信を開始したと判定した場合、処理はステップＳ５９に進む。
　ステップＳ５９において、パケットヘッダ検出部８１は、ステップＳ５８で検出したパケットヘッダのデータタイプを確認して、受信を開始したパケットが拡張モードに対応した拡張パケットであるか否かを判定する。例えば、パケットヘッダ検出部８１は、パケットヘッダのデータタイプにおいて、拡張モード設定情報が拡張モードであることを示す場合（DataType[5:3]=3’b111）、受信を開始したパケットが拡張パケットであると判定する。
　ステップＳ５９において、パケットヘッダ検出部８１が、受信を開始したパケットが拡張パケットであると判定した場合、処理はステップＳ６０に進み、拡張パケットを受信する拡張モード受信処理（図１４参照）が行われる。
　一方、ステップＳ５９において、パケットヘッダ検出部８１が、受信を開始したパケットが拡張パケットでないと判定した場合、処理はステップＳ６１に進む。
　ステップＳ６１において、パケットヘッダ検出部８１は、ステップＳ５８で検出したパケットヘッダのデータタイプ（DataType[5:0]）を確認して、受信を開始したパケットがショートパケットであるか否かを判定する。
　ステップＳ６１において、パケットヘッダ検出部８１が、受信を開始したパケットがショートパケットであると判定した場合、処理はステップＳ６２に進む。ステップＳ６２において、パケットヘッダ検出部８１は、イメージセンサ２１から送信されてくる従来のパケット構造のショートパケットを受信する。
　一方、ステップＳ６１において、パケットヘッダ検出部８１が、受信を開始したパケットがショートパケットでない（即ち、ロングパケットの受信を開始している）と判定した場合、処理はステップＳ６３に進む。ステップＳ６３において、アンパッキング部８７は、イメージセンサ２１から送信されてくる従来のパケット構造のロングパケットのペイロードを受信して画像データを取り出し、CRC演算部８６は、パケットヘッダに続けて送信されてくるWC＋１バイト目をCRCとして受信する。
　ステップＳ６０、ステップＳ６２、またはステップＳ６３の処理後、処理はステップＳ６４に進み、コントローラ７４は、パケット受信処理を終了する。その後、処理はステップＳ５８に戻り、以下、次のパケットを対象として、同様にパケットを受信する処理が繰り返して行われる。
　図１４は、図１３のステップＳ６０の処理で行われる拡張モード受信処理を説明するフローチャートである。
　ステップＳ７１において、パケットヘッダ検出部８１は、拡張モードのモード設定が拡張モード０であるか否かを判定する。例えば、パケットヘッダ検出部８１は、パケットヘッダのデータタイプにおいて、拡張タイプ設定情報が拡張モード０であることを示す場合（DataType[1:0] =2’b00）、拡張モードのモード設定が拡張モード０であると判定する。
　ステップＳ７１において、パケットヘッダ検出部８１が、拡張モードのモード設定が拡張モード０であると判定した場合、処理はステップＳ７２に進む。ステップＳ７２において、解釈部８３は、ペイロードの１バイト目を拡張パケットヘッダとして受信する。
　ステップＳ７３において、解釈部８３は、ステップＳ７２で受信した拡張パケットヘッダのデータタイプ（DataType[7:0]）を確認して、受信を開始したパケットが拡張ショートパケットであるか否かを判定する。
　ステップＳ７３において、解釈部８３が、拡張ショートパケットであると判定した場合、処理はステップＳ７４に進む。ステップＳ７４において、解釈部８３は、ステップＳ７２で受信した拡張パケットヘッダに格納されている設定（OePH[7:0]）に従って、オプショナル拡張パケットヘッダを受信する。
　ステップＳ７５において、CRC演算部８６は、オプショナル拡張パケットヘッダに続けて送信されてくるWC＋１バイト目をCRCとして受信する。
　一方、ステップＳ７３において、解釈部８３が、拡張ショートパケットでない（即ち、拡張ロングパケットの受信を開始している）と判定した場合、処理はステップＳ７６に進む。ステップＳ７６において、解釈部８３は、ステップＳ７２で受信した拡張パケットヘッダに格納されている設定（OePH[7:0]）に従って、オプショナル拡張パケットヘッダを受信する。
　ステップＳ７７において、アンパッキング部８７は、イメージセンサ２１から送信されてくる拡張ロングパケットのレガシーペイロードを受信して画像データを取り出す。
　ステップＳ７８において、解釈部８３は、ステップＳ７２で受信した拡張パケットヘッダに格納されている設定（OePF[3:0]）に従って、オプショナル拡張パケットフッタを受信する。
　ステップＳ７９において、CRC演算部８６は、オプショナル拡張パケットフッタに続けて送信されてくるWC＋１バイト目をCRCとして受信する。
　そして、ステップＳ７１で拡張モードのモード設定が拡張モード０でないと判定した場合、ステップＳ７５の処理後、またはステップＳ７９の処理後、拡張モード受信処理は終了される。
　以上のように、アプリケーションプロセッサ２２は、拡張ショートパケットまたは拡張ロングパケットを受信して、データを取得することができる。
　＜パケット構造の第２の構造例＞
　図１５乃至図１８を参照して、拡張モード対応CSI-2送信回路３１および拡張モード対応CSI-2受信回路３２の間の通信で用いられるパケットのパケット構造の第２の構造例について説明する。
　上述の図３乃至図８に示した第１の構造例では、既存のCSI-2規格の互換性を維持することを重視して、パケットヘッダおよびパケットフッタが既存のCSI-2規格と同一のパケット構造とし、拡張パケットヘッダ、オプショナル拡張パケットヘッダ、およびオプショナル拡張パケットフッタによりパケット構造の拡張が図られている。これに対し、以下で説明する第２の構造例では、パケットヘッダおよびパケットフッタを既存のCSI-2規格と異なるものとし、拡張パケットヘッダおよび拡張パケットフッタによりパケット構造の拡張が図られる。
　図１５には、物理層がD-PHYである場合にCSI-2の拡張モードで用いられるショートパケット（以下、D-PHY用の拡張ショートパケット）のパケット構造が示されている。
　図１５に示すD-PHY用の拡張ショートパケットは、図４に示した第１の構造例のD-PHY用の拡張ショートパケットと同様に、既存のCSI-2規格と同一のパケットヘッダに格納されるデータタイプによって拡張モードが識別される。
　一方、図１５に示すD-PHY用の拡張ショートパケットでは、パケットヘッダのデータタイプの次の１６ビットに、既存のCSI-2規格に従ったショートパケットと同様に、ショートパケットデータフィールドにフレームナンバーが格納される。そして、パケットヘッダに続いて、図４に示した拡張パケットヘッダと同様に構成される拡張パケットヘッダが送信される。
　従って、受信側となるアプリケーションプロセッサ２２は、拡張パケットヘッダに格納されているデータタイプを解釈して、拡張ショートパケットである場合に、パケットヘッダのデータフィールドにフレームナンバーが格納されていることを判別することができる。
　なお、図１５に示すD-PHY用の拡張ショートパケットにおけるオプショナル拡張パケットヘッダは、図４に示した第１の構造例のD-PHY用の拡張ショートパケットにおけるオプショナル拡張パケットヘッダと同様に構成される。しかしながら、オプショナル拡張パケットヘッダは、ペイロードに埋め込まれないパケット構造となっていることより、最後にCRCを付与する必要はない。
　図１６には、物理層がD-PHYである場合にCSI-2の拡張モードで用いられるロングパケット（以下、D-PHY用の拡張ロングパケット）のパケット構造が示されている。
　図１６に示すD-PHY用の拡張ロングパケットでは、拡張データはペイロードに埋め込まず、パケットヘッダまたはパケットフッタの一部として伝送される。従って、先頭のパケットヘッダのWCは既存規格と同様に、あくまでペイロードのバイト長を示す。
　図１７には、物理層がC-PHYである場合にCSI-2の拡張モードで用いられるショートパケット（以下、C-PHY用の拡張ショートパケット）のパケット構造が示されている。
　図１７に示すC-PHY用の拡張ショートパケットにおける拡張部分は、あくまで既存のCSI-2規格に従ったパケットヘッダの拡張として伝送されるため、フレームナンバーの後に拡張パケットヘッダなど拡張部分が挿入される。そして、既存のCSI-2規格と同様に、パケットヘッダはCRCで終了する。さらに、これらを、SYNCを挟んで２回伝送するパケット構造は、既存のCSI-2規格に従ったショートパケットと同様である。
　図１８には、物理層がC-PHYである場合にCSI-2の拡張モードで用いられるロングパケット（以下、C-PHY用の拡張ロングパケット）のパケット構造が示されている。
　図１８に示すC-PHY用の拡張ロングパケットは、上述したように、先頭のパケットヘッダのWCは既存規格と同様に、あくまでペイロードのバイト長を示す点で、図８に示した第１の構造例のC-PHY用の拡張ロングパケットと差異がある。
　以上のように図１５乃至図１８に示す第２の構造例の拡張パケットのパケット構造により、第１の構造例の拡張パケットのパケット構造（図３乃至図８）と同様に、従来よりも多様な用途に対応することが可能となる。
　ただし、第２の構造例の拡張パケットは、既存のペイロードに拡張データが埋め込まれずに、既存のパケットヘッダやフッタが拡張されるパケット構造となっている。このため、第２の構造例の拡張パケットのパケット構造を採用する場合には、第１の構造例の拡張パケットのパケット構造を採用する場合と比較して、従来から用いられている通信システムから変更が必要となるような影響を最小限とすることができない。即ち、例えば、既存のSerDes送信回路３４がSerDes受信回路３５（図２）に対する変更が必要となる。
　以上のように、第１の構造例の拡張パケットを採用することで、車載など多彩な用途への対応することができ、かつ、従来から用いられている通信システムから変更が必要となるような影響を最小限として、車載システムを構築することができる。
　また、第２の構造例の拡張パケットを採用することで、従来から用いられている通信システムから変更が必要となるものの、車載など多彩な用途への対応することができる。
　＜イメージセンサおよびアプリケーションプロセッサの変形例＞
　（イメージセンサの変形例）
　図１９を参照して、イメージセンサおよびアプリケーションプロセッサの変形例について説明する。
　上述した図９のイメージセンサ２１および図１０のアプリケーションプロセッサ２２を構成する各ブロックは、D-PHY用およびC-PHY用のパケットの両方に対応して処理を行えるように構成されていた。これに対し、例えば、D-PHY用のパケットを専用に処理を行うブロックと、C-PHY用のパケットを専用に処理を行うブロックとの両方を備え、それぞれで処理を切り替えるようにしてもよい。
　図１９のＡに示すイメージセンサ２１Ａは、Ｄ層処理ブロック部１０１、Ｃ層処理ブロック部１０２、切り替え部１０３、およびコントローラ６０を備えて構成される。
　Ｄ層処理ブロック部１０１は、図９のイメージセンサ２１を構成するブロックのうち、D-PHY用のパケットを専用に処理を行うブロックを有している。Ｃ層処理ブロック部１０２は、図９のイメージセンサ２１を構成するブロックのうち、C-PHY用のパケットを専用に処理を行うブロックを有している。切り替え部１０３は、コントローラ６０による制御に従って、物理層にD-PHYを用いる場合には、Ｄ層処理ブロック部１０１において生成されるD-PHY用のパケットを出力し、物理層にC-PHYを用いる場合には、Ｃ層処理ブロック部１０２において生成されるC-PHY用のパケットを出力するように切り替えを行う。
　（アプリケーションプロセッサの変形例）
　図１９のＢに示すアプリケーションプロセッサ２２Ａは、切り替え部１１１、Ｄ層処理ブロック部１１２、Ｃ層処理ブロック部１１３、およびコントローラ７４を備えて構成される。
　切り替え部１１１は、コントローラ７４による制御に従って、イメージセンサ２１Ａから送信されてくるパケットを、Ｄ層処理ブロック部１１２およびＣ層処理ブロック部１１３の一方に供給するように切り替えを行う。Ｄ層処理ブロック部１１２は、図１０のアプリケーションプロセッサ２２を構成するブロックのうち、D-PHY用のパケットを専用に処理を行うブロックを有している。Ｃ層処理ブロック部１１３は、図１０のアプリケーションプロセッサ２２を構成するブロックのうち、C-PHY用のパケットを専用に処理を行うブロックを有している。
　このように構成されるイメージセンサ２１Ａおよびアプリケーションプロセッサ２２Ａでは、通信を開始する前に、コントローラ６０およびコントローラ７４の間で、使用する物理層を設定することができる。そして、例えば、物理層にD-PHYが用いられる場合には、Ｄ層処理ブロック部１０１において生成されるD-PHY用のパケットが切り替え部１０３を介して送信され、切り替え部１１１を介してＤ層処理ブロック部１１２に供給されて処理される。また、例えば、物理層にC-PHYが用いられる場合には、Ｃ層処理ブロック部１０２において生成されるC-PHY用のパケットが切り替え部１０３を介して送信され、切り替え部１１１を介してＣ層処理ブロック部１１３に供給されて処理される。
　＜拡張パケットの適用例＞
　上述した拡張パケットは、例えば、以下のようなユースケースに適用することが検討されている。
　例えば、拡張パケットは、より高精細な画像（RAW24）を伝送するようなユースケースに適用することが検討される。
　例えば、画像データをRAW形式で送信する際に、既存のCSI-2規格に従ってパケットヘッダに格納されるデータタイプとして、RAW6，RAW7，RAW8，RAW10，RAW12，RAW14，RAW16、およびRAW20が定義されている。これに対し、近年、車載カメラを用いた自動運転に対応するため、より高精細な画像の伝送が期待されている。そこで、拡張パケットを適用してデータタイプのビット数を拡張することで、例えば、拡張パケットヘッダのデータタイプに、より高精細なRAW24を定義することが可能となる。
　また、拡張パケットは、画面上の注目画像領域のみを伝送する技術であるSmartROIに適用することが検討される。
　例えば、現在、スタジアムや空港などには多数のカメラが設置されている。これらのカメラで撮像した画像の全体が、カメラからインターネットなどのネットワークを経由してクラウドサーバに伝送される場合、インターネットの帯域不足や、クラウド側の計算量またはデータ量の増大などが発生することが想定される。そのため、エッジ（カメラ側）で注目画像領域のみを切り出し、その注目画像領域を伝送することで、インターネットの帯域不足や、クラウド側の計算量またはデータ量の増大などを抑制することが期待される。
　このようなSROIを伝送する場合、注目画像領域が画面全体のどこに相当するか受信側に伝えるため、矩形領域(ROI)の左上の座標を一緒に伝送する必要がある。また、受信側からの命令で、所定のタイミングで、撮像画面全体のデータを送る必要がある。従って、例えばフレーム単位でSROI画像と、画像全体（既存のパケットヘッダ）のデータが混在することになる。
　そこで、拡張パケットを適用することで、例えば、X座標およびY座標それぞれ16bit以上の座標データを伝送することが可能となる。
　さらに、拡張パケットは、チャネル劣化した場合においても帯域やレーン数を減らして通信を継続するGLDに適用するユースケースが検討される。なお、GLDは、CSI-2 ver3.0で検討されている提案である。
　例えば、自動運転では、衝突時にカメラを繋ぐケーブルの一部が断線したとしても、断線していないケーブルを使用して通信を継続し、自動的に、安全帯に退避した後に車両を停止することが求められる。そのため、車載用カメラインタフェースが断線検出機能を少なくとも備え、画面上の何行目の情報か示す行番号（16bit）や、どのカメラから送られたことかを示すSourceID（8bit）、伝送番号を示すメッセージカウンタ（16bit）などの情報が必要になる。さらに、上述したようなSROIと組み合わせて使用される場合には、フレーム単位で、これらの情報が伝送されることが考えられる。
　そこで、拡張パケットを適用することで、これらの情報を伝送することが可能となる。
　＜E2E protectionに適応した第１の構成例＞
　図２０乃至図２６を参照して、伝送経路上におけるパケット改変等を禁止する規定に適応した構成例について説明する。
　例えば、上述の図２を参照して説明したような構成の通信システム１１Ａにおいて、イメージセンサ２１とアプリケーションプロセッサ２２とでインタフェースが異なっている場合、伝送経路上においてパケットを変換することが必要となる。つまり、イメージセンサ２１の物理層がD-PHYであって、アプリケーションプロセッサ２２の物理層がC-PHYである構成の場合、例えば、SerDes装置２６においてD-PHY用からC-PHY用にパケットを変換することが必要となる。
　このように、SerDes装置２６においてパケット変換が行われてしまう構成では、例えば、ISO26262（Functional Safety）が定める規定、即ち、伝送経路上におけるパケット改変等を禁止する規定（以下、E2E(End-toEnd) protectionと称する）に違反することになる。
　図２０は、本技術を適用した通信システムの第３の実施の形態として、E2E protectionに適応した通信システム２０１の構成例を示すブロック図である。
　図２０に示すように、通信システム２０１は、イメージセンサ２１１、SerDes装置２１２、SerDes装置２１３、およびアプリケーションプロセッサ２１４が接続されて構成される。なお、図２０は、SERDESがA-PHYの場合を例として記載しているが、FPD-LINK3等のような他のSERDES規格を用いて接続される場合も含まれる。その他、SERDES規格においては、CIS-2のフォーマット（少なくともApplication Specific payload）を保ったまま、当該SERDES規格に基づいて通信が行われてもよい。また、SERDESにおいては、物理層処理部２３７および２４７はA-PHY以外にも他のSERDES規格の物理層処理部を複数含んでいてもよく、アプリケーションに応じて、物理層処理部を切り替えることができる。
　イメージセンサ２１１は、拡張モード対応CSI-2送信回路２２１、C-PHYあるいはD-PHY、またはその両方に対応した物理層処理部（以下、C/D-PHY物理層処理部と称する）２２２、I2CあるいはI3C、またはその両方に対応したスレーブ（以下、I2C/I3Cスレーブと称する）２２３、並びに、CCIスレーブ２２４を少なくとも有している。
　SerDes装置２１２は、CSI-2受信回路２３１、C/D-PHY物理層処理部２３２、I2C/I3Cマスタ２３３、CCIマスタ２３４、CSI-2用A-PHYパケット生成部２３５、CCI用A-PHYパケット送受信部２３６、並びに、A-PHYに対応した物理層処理部２３７を少なくとも有している。例えば、SerDes装置２１２では、C-PHY用またはD-PHY用のパケットがA-PHY用のパケットに変換され、この変換は、レジスタ設定などに基づいて決められる。
　SerDes装置２１３は、CSI-2送信回路２４１、C/D-PHY物理層処理部２４２、I2C/I3Cスレーブ２４３、CCIスレーブ２４４、CSI-2用A-PHYパケット受信部２４５、CCI用A-PHYパケット送受信部２４６、A-PHYに対応した物理層処理部２４７を少なくとも有している。例えば、SerDes装置２１３では、A-PHY用のパケットがC-PHY用またはD-PHY用のパケットに変換され、この変換は、レジスタ設定などに基づいて決められる。
　アプリケーションプロセッサ２１４は、拡張モード対応CSI-2受信回路２５１、C/D-PHY物理層処理部２５２、I2C/I3Cマスタ２５３、並びに、CCIマスタ２５４を少なくとも有している。
　このように通信システム２０１は構成されており、上述したような構造の拡張パケットがイメージセンサ２１１から送信されて、アプリケーションプロセッサ２１４で受信される。ここで、イメージセンサ２１１の物理層処理部２２２がD-PHYに対応し、アプリケーションプロセッサ２２の物理層処理部２５２がC-PHYに対応するように通信システム２０１が構成されていても、E2E protectionに違反しないようにすることが必要となる。
　そこで、通信システム２０１は、E2E protectionに適応することができるように、E2Eprotectionの保護範囲を、アプリケーションに特有のペイロードであるApplication Specific payload（以下、ASペイロードと称する）に限定する。即ち、ASペイロードは、A-PHY用のパケットからC-PHY用またはD-PHY用のパケットへの変換時や、C-PHY用またはD-PHY用のパケットからA-PHY用のパケットへの変換時に変更を加えることが禁止される。
　図２１には、E2E protectionに対応するように拡張されたD-PHY用の拡張パケットの構造例が示されている。
　図示するように、D-PHY用の拡張パケットは、拡張パケットヘッダ（ePH）、パケットデータ、および拡張パケットフッタ（ePF）からなるASペイロードが、E2E protectionの保護範囲として限定される。
　そして、拡張パケットヘッダには、E2E protectionの保護範囲をASペイロードに限定した場合に必要となる所定情報が記載される。例えば、拡張パケットヘッダに記載される所定情報として、パケットデータのデータ長を同定することができるようにするために、ASペイロードに格納されるデータのデータ長を示すパケットカウントPC（Packet Count）が追加される。即ち、パケットデータは、パケットカウントPCで定められたバイト数となる。また、拡張パケットヘッダに記載される所定情報として、仮想チャネルの回線数を示すバーチャルチャネルVC（Virtual Channel）が、既存のパケットヘッダへコピーされる。
　図２２には、E2E protectionに対応するように拡張されたC-PHY用の拡張パケットの構造例が示されている。
　図示するように、C-PHY用の拡張パケットは、D-PHY用の拡張パケットと同様に、拡張パケットヘッダ（ePH）、パケットデータ、および拡張パケットフッタ（ePF）からなるASペイロードが、E2E protectionの保護範囲として限定される。そして、拡張パケットヘッダには、D-PHY用の拡張パケットと同様に、E2E protectionの保護範囲をASペイロードに限定した場合に必要となる所定情報として、パケットカウントPCおよびバーチャルチャネルVCが記載される。
　図２３には、E2E protectionに対応するように拡張されたA-PHY用の拡張パケットの構造例が示されている。
　図示するように、A-PHY用の拡張パケットにおいても、拡張パケットヘッダ（ePH）、パケットデータ、および拡張パケットフッタ（ePF）からなるASペイロードが、E2E protectionの保護範囲として限定される。
　ここで、通信システム２０１は、図２０を参照して説明したように、イメージセンサ２１１からSerDes装置２１２に送信されたD-PHY用またはC-PHY用の拡張パケットからA-PHY用の拡張パケットが生成される。従って、A-PHY用の拡張パケットの拡張パケットヘッダには、パケットカウントPCおよびバーチャルチャネルVCが既に記載されている。
　このようなパケット構造を採用することで、通信システム２０１は、伝送経路上においてASペイロードが改変されることを回避して、E2E protectionを順守することが可能となる。なお、図２１乃至図２３に示したパケット構造は、図３乃至図８および図１５乃至図１８に示したようなパケット構造の該当するパケットと部分的に置き換えて用いることができ、パケット生成の一部が置き換えられる。
　＜E2E protectionに適応したパケット送受信処理＞
　図２４は、E2E protectionに適応したパケット送受信処理を説明するフローチャートである。
　例えば、パケットデータに格納するデータ（例えば、画像データなど）が拡張モード対応CSI-2送信回路２２１に供給されると処理が開始される。そして、ステップＳ１０１において、イメージセンサ２１１では、拡張モード対応CSI-2送信回路２２１が、供給されたデータをパケットデータに格納する。さらに、拡張モード対応CSI-2送信回路２２１は、上述の図２１または図２２に示したようにバーチャルチャネルVCおよびパケットカウントPCを記載した拡張パケットヘッダを生成する。そして、拡張モード対応CSI-2送信回路２２１は、パケットデータに対して、拡張パケットヘッダを付加するとともに、拡張パケットフッタを付加することにより、ASペイロードを生成する。
　ステップＳ１０２において、拡張モード対応CSI-2送信回路２２１は、ステップＳ１０１で生成したASペイロードに対して、C-PHY用またはD-PHY用のパケットヘッダとC-PHY用またはD-PHY用のパケットフッタとを付加することにより、C-PHY用またはD-PHY用の拡張パケットを生成する。そして、拡張モード対応CSI-2送信回路２２１は、C/D-PHY物理層処理部２２２を介して、C-PHY用またはD-PHY用の拡張パケットをSerDes装置２１２に送信する。
　ステップＳ１０３において、SerDes装置２１２では、CSI-2受信回路２３１が、C/D-PHY物理層処理部２３２を介して、ステップＳ１０２でイメージセンサ２１１から送信されてくるC-PHY用またはD-PHY用の拡張パケットを受信する。そして、CSI-2受信回路２３１は、受信した拡張パケットからパケットヘッダおよびパケットフッタを除いたASペイロードを取得し、ASペイロードをそのままCSI-2用A-PHYパケット生成部２３５に供給する。
　ステップＳ１０４において、SerDes装置２１２では、CSI-2用A-PHYパケット生成部２３５が、CSI-2受信回路２３１から供給されたASペイロードに対して、A-PHY用のパケットヘッダとA-PHY用のパケットフッタを付加することにより、A-PHY用の拡張パケットを生成する。そして、CSI-2用A-PHYパケット生成部２３５は、A-PHYに対応した物理層処理部２３７を介して、A-PHY用の拡張パケットをSerDes装置２１３に送信する。
　ステップＳ１０５において、SerDes装置２１３では、CSI-2用A-PHYパケット受信部２４５が、A-PHYに対応した物理層処理部２４７を介して、ステップＳ１０４でSerDes装置２１２から送信されてくるA-PHY用の拡張パケットを受信する。そして、CSI-2用A-PHYパケット受信部２４５は、受信した拡張パケットからパケットヘッダおよびパケットフッタを除いたASペイロードを取得し、ASペイロードをそのままCSI-2送信回路２４１に供給する。
　ステップＳ１０６において、CSI-2送信回路２４１は、ステップＳ１０５でCSI-2用A-PHYパケット受信部２４５から供給されたASペイロードに対して、C-PHY用またはD-PHY用のパケットヘッダとC-PHY用またはD-PHY用のパケットフッタとを付加することにより、C-PHY用またはD-PHY用の拡張パケットを生成する。そして、CSI-2送信回路２４１は、C/D-PHY物理層処理部２４２を介して、C-PHY用またはD-PHY用の拡張パケットをアプリケーションプロセッサ２１４に送信する。
　ステップＳ１０７において、アプリケーションプロセッサ２１４では、拡張モード対応CSI-2受信回路２５１が、C/D-PHY物理層処理部２５２を介して、ステップＳ１０６でSerDes装置２１３から送信されてくるC-PHY用またはD-PHY用の拡張パケットを受信する。そして、拡張モード対応CSI-2受信回路２５１は、受信した拡張パケットからパケットヘッダおよびパケットフッタを除いたASペイロードを取得して、ASペイロードのパケットデータに格納されている各種のデータを、後段のLSI（図示せず）へ出力する。その後、E2E protectionに適応したパケット送受信処理は終了され、次の拡張パケットを対象として、同様の処理が繰り返して行われる。
　以上のように、通信システム２０１は、E2E protectionに適応したパケット送受信処理を実行することによって、伝送経路上でASペイロードを改変することなく、拡張パケットを送受信することができる。このとき、例えば、イメージセンサ２１１の物理層がD-PHYであって、アプリケーションプロセッサ２１４の物理層がC-PHYである場合であっても、即ち、それぞれのインタフェースが異なっている場合であっても、E2E protectionを順守することができる。
　＜イメージセンサ２１１の詳細な構成例＞
　図２５は、イメージセンサ２１１の詳細な構成例を示すブロック図である。なお、図２５に示すイメージセンサ２１１において、図９のイメージセンサ２１と共通する構成には、同一の符号を付し、その詳細な説明は省略する。
　即ち、イメージセンサ２１１は、図９のイメージセンサ２１と同様に、画素４１、AD変換器４２、画像処理部４３、レジスタ４７、およびコントローラ６０を備えて構成される。また、イメージセンサ２１１が備えるI2C/I3Cスレーブ２２３およびCCIスレーブ２２４は、図９のI2C/I3Cスレーブ４６およびCCIスレーブ５９にそれぞれ対応する。
　そして、イメージセンサ２１１は、拡張モード対応CSI-2送信回路２２１および物理層処理部２２２を備えており、物理層処理部２２２は、A-PHY、C-PHY、およびD-PHYに対応している。
　拡張モード対応CSI-2送信回路２２１は、コントローラ６０およびCCIスレーブ２２４の他、ASペイロード生成部３０１、セレクタ３０２、A-PHYパケット生成部３０３、C-PHYパケット生成部３０４、D-PHYパケット生成部３０５、およびセレクタ３０６を備えて構成される。
　ASペイロード生成部３０１は、E2E protectionの保護範囲として限定されるASペイロードを生成して、セレクタ３０２に出力する。例えば、ASペイロード生成部３０１は、パッキング部３１１、拡張パケットヘッダ生成部３１２、および拡張パケットフッタ生成部３１３を有している。
　パッキング部３１１は、送信対象のデータとして画像処理部４３から供給される画像データをパッキングし、パケットカウントPCで定められたバイト数のパケットデータを生成する。例えば、コントローラ６０が、レジスタ４７に記憶されている設定値（例えば、画像サイズなど）に従って、パッキング部３１１が生成するパケットデータのバイト数を制御することができる。
　拡張パケットヘッダ生成部３１２は、例えば、図２１乃至図２３を参照して説明したように、パケットカウントPCおよびバーチャルチャネルVCを記載した拡張パケットヘッダを生成して、パケットデータに付加する。拡張パケットフッタ生成部３１３は、拡張パケットフッタを生成してパケットデータに付加する。
　セレクタ３０２は、コントローラ６０の制御に従って、ASペイロード生成部３０１から供給されるASペイロードの出力先として、並列に設けられるA-PHYパケット生成部３０３、C-PHYパケット生成部３０４、およびD-PHYパケット生成部３０５のうちの１つを選択する。
　A-PHYパケット生成部３０３は、セレクタ３０２を介して供給されるASペイロードからA-PHY用の拡張パケットを生成して、セレクタ３０６に出力する。例えば、A-PHYパケット生成部３０３は、AAL生成部３２１、A-PHY用パケットヘッダ生成部３２２、およびA-PHY用パケットフッタ生成部３２３を有している。
　例えば、AAL（A-PHY Adaptation Layer）生成部３２１は、ASペイロード生成部３０１で生成されたASペイロードを、Adaptation Layerと称される階層で380byteごとに分割する。そして、分割後のASペイロードに対して、A-PHY用パケットヘッダ生成部３２２がA-PHY用のパケットヘッダを付加し、A-PHY用パケットフッタ生成部３２３がA-PHY用のパケットフッタを付加する。
　C-PHYパケット生成部３０４は、セレクタ３０２を介して供給されるASペイロードからC-PHY用の拡張パケットを生成して、セレクタ３０６に出力する。例えば、C-PHYパケット生成部３０４は、C-PHY用パケットヘッダ生成部３３１、C-PHY用パケットフッタ生成部３３２、およびC-PHY用レーン分配部３３３を有している。
　例えば、ASペイロード生成部３０１で生成されたASペイロードに対して、C-PHY用パケットヘッダ生成部３３１がC-PHY用のパケットヘッダを付加し、C-PHY用パケットフッタ生成部３３２がC-PHY用のパケットフッタを付加する。そして、C-PHY用レーン分配部３３３は、C-PHY用の拡張パケットを、CSI-2の規格に従った３レーンに分配する。
　D-PHYパケット生成部３０５は、セレクタ３０２を介して供給されるASペイロードからD-PHY用の拡張パケットを生成して、セレクタ３０６に出力する。例えば、D-PHYパケット生成部３０５は、D-PHY用パケットヘッダ生成部３４１、D-PHY用パケットフッタ生成部３４２、およびD-PHY用レーン分配部３４３を有している。
　例えば、ASペイロード生成部３０１で生成されたASペイロードに対して、D-PHY用パケットヘッダ生成部３４１がD-PHY用のパケットヘッダを付加し、D-PHY用パケットフッタ生成部３４２がD-PHY用のパケットフッタを付加する。そして、D-PHY用レーン分配部３４３は、D-PHYの拡張パケットを、CSI-2の規格に従った４レーンに分配する。
　セレクタ３０６は、コントローラ６０の制御に従って、物理層処理部２２２に供給される拡張パケットの出力元として、並列に設けられるA-PHYパケット生成部３０３、C-PHYパケット生成部３０４、およびD-PHYパケット生成部３０５のうちの１つを選択する。
　そして、物理層処理部２２２は、A-PHYパケット生成部３０３からA-PHY用の拡張パケットが供給された場合には、１レーンでA-PHY用の拡張パケットを送信する。また、物理層処理部２２２は、C-PHYパケット生成部３０４からC-PHY用の拡張パケットが供給された場合には、３レーンでC-PHY用の拡張パケットを送信する。また、物理層処理部２２２は、D-PHYパケット生成部３０５からD-PHY用の拡張パケットが供給された場合には、４レーンでD-PHY用の拡張パケットを送信する。
　以上のように構成されるイメージセンサ２１１は、ASペイロード生成部３０１が、セレクタ３０２を介して、A-PHYパケット生成部３０３、C-PHYパケット生成部３０４、およびD-PHYパケット生成部３０５に接続されるように拡張モード対応CSI-2送信回路２２１が構成される。これにより、イメージセンサ２１１は、A-PHY用の拡張パケット、C-PHY用の拡張パケット、およびD-PHY用の拡張パケットで共通するASペイロードを、１つのASペイロード生成部３０１で生成することができる。即ち、A-PHYパケット生成部３０３、C-PHYパケット生成部３０４、およびD-PHYパケット生成部３０５でASペイロード生成部３０１を共有することができ、これにより回路規模の縮小を図ることができる。従って、イメージセンサ２１１の小型化を実現することができる。
　＜アプリケーションプロセッサ２１４の詳細な構成例＞
　図２６は、アプリケーションプロセッサ２１４の詳細な構成例を示すブロック図である。なお、図２６に示すアプリケーションプロセッサ２１４において、図１０のアプリケーションプロセッサ２２と共通する構成には、同一の符号を付し、その詳細な説明は省略する。
　即ち、アプリケーションプロセッサ２１４は、図１０のアプリケーションプロセッサ２２と同様に、レジスタ７３、およびコントローラ７４を備えて構成される。なお、コントローラ７４は、ソフトウェアにより実現してもよい。また、アプリケーションプロセッサ２１４が備えるI2C/I3Cマスタ２５３およびCCIマスタ２５４は、図１０のI2C/I3Cマスタ７２およびCCIマスタ８８にそれぞれ対応する。
　そして、アプリケーションプロセッサ２１４は、拡張モード対応CSI-2受信回路２５１および物理層処理部２５２を備えており、物理層処理部２５２は、A-PHY、C-PHY、およびD-PHYに対応している。
　拡張モード対応CSI-2受信回路２５１は、CCIマスタ２５４の他、セレクタ４０１、A-PHYパケット受信部４０２、C-PHYパケット受信部４０３、D-PHYパケット受信部４０４、セレクタ４０５、およびASペイロード受信部４０６を備えて構成される。
　セレクタ４０１は、物理層処理部２５２から供給される拡張パケットの出力先として、並列に設けられるA-PHYパケット受信部４０２、C-PHYパケット受信部４０３、およびD-PHYパケット受信部４０４のうちの１つを選択する。
　A-PHYパケット受信部４０２は、セレクタ４０１を介して供給されるA-PHY用の拡張パケットを受信して、セレクタ４０５に出力する。例えば、A-PHYパケット受信部４０２は、A-PHY用パケットヘッダ解釈部４１１、A-PHY用パケットフッタ検証部４１２、およびAAL処理部４１３を有している。
　例えば、A-PHY用パケットヘッダ解釈部４１１は、A-PHY用のパケットヘッダに記載されている内容を解釈して、A-PHY用の拡張パケットの受信に必要な処理を行い、A-PHY用パケットフッタ検証部４１２は、A-PHY用のパケットフッタを用いてエラーの有無を検証する。そして、AAL処理部４１３は、図２５のAAL生成部３２１において分割されたAdaptationLayerを結合する処理を行う。
　C-PHYパケット受信部４０３は、セレクタ４０１を介して供給されるC-PHY用の拡張パケットを受信して、セレクタ４０５に出力する。例えば、C-PHYパケット受信部４０３は、C-PHY用レーン併合部４２１、C-PHY用パケットヘッダ解釈部４２２、およびC-PHY用パケットフッタ検証部４２３を有している。
　例えば、C-PHY用レーン併合部４２１は、CSI-2の規格に従って３レーンに分配されて物理層処理部２５２を介して供給されるC-PHY用の拡張パケットを併合する。そして、C-PHY用パケットヘッダ解釈部４２２は、C-PHY用のパケットヘッダに記載されている内容を解釈して、C-PHY用の拡張パケットの受信に必要な処理を行い、C-PHY用パケットフッタ検証部４２３は、C-PHY用のパケットフッタを用いてエラーの有無を検証する。
　D-PHYパケット受信部４０４は、セレクタ４０１を介して供給されるD-PHY用の拡張パケットを受信して、セレクタ４０５に出力する。例えば、D-PHYパケット受信部４０４は、D-PHY用レーン併合部４３１、D-PHY用パケットヘッダ解釈部４３２、およびD-PHY用パケットフッタ検証部４３３を有している。
　例えば、D-PHY用レーン併合部４３１は、CSI-2の規格に従って４レーンに分配されて物理層処理部２５２を介して供給されるD-PHY用の拡張パケットを併合する。そして、D-PHY用パケットヘッダ解釈部４３２は、D-PHY用のパケットヘッダに記載されている内容を解釈して、D-PHY用の拡張パケットの受信に必要な処理を行い、D-PHY用パケットフッタ検証部４３３は、D-PHY用のパケットフッタを用いてエラーの有無を検証する。
　セレクタ４０５は、ASペイロード受信部４０６に供給される拡張パケットの出力元として、並列に設けられるA-PHYパケット受信部４０２、C-PHYパケット受信部４０３、およびD-PHYパケット受信部４０４のうちの１つを選択する。
　ASペイロード受信部４０６は、図２５のASペイロード生成部３０１に対応して、アンパッキング部４４１、拡張パケットヘッダ解釈部４４２、および拡張パケットフッタ検証部４４３を有している。アンパッキング部４４１は、パッキング部３１１によりパッキングされた画像データをアンパッキングする。拡張パケットヘッダ解釈部４４２は、拡張パケットヘッダ生成部３１２において生成された拡張パケットヘッダを解釈し、例えば、パケットカウントPCおよびバーチャルチャネルVCを読み出す。拡張パケットフッタ検証部４４３は、拡張パケットフッタ生成部３１３により付加された拡張パケットフッタを用いてエラーの有無を検証する。そして、ASペイロード受信部４０６は、セレクタ４０５を介して供給されるパケットデータに格納されている各種のデータ、例えば、画像データ、車載用行番号やSourceIDなど、CRCエラーなどを、後段のLSI（図示せず）へ出力する。
　以上のように構成されるアプリケーションプロセッサ２１４は、ASペイロード受信部４０６が、セレクタ４０５を介して、A-PHYパケット受信部４０２、C-PHYパケット受信部４０３、およびD-PHYパケット受信部４０４に接続されるように拡張モード対応CSI-2受信回路２５１が構成される。これにより、アプリケーションプロセッサ２１４は、A-PHY用の拡張パケット、C-PHY用の拡張パケット、およびD-PHY用の拡張パケットで共通するASペイロードを、１つのASペイロード受信部４０６で受信することができる。即ち、A-PHYパケット受信部４０２、C-PHYパケット受信部４０３、およびD-PHYパケット受信部４０４でASペイロード受信部４０６を共有することができ、これにより回路規模の縮小を図ることができる。従って、アプリケーションプロセッサ２１４の小型化を実現することができる。
　＜E2E Protectionに適応した第２の構成例＞
　図２７乃至図７４を参照して、E2E Protectionに適応した第２の構成例について説明する。
　＜A-PHY直結構成の構成例＞
　図２７に示す通信システム５０１は、イメージセンサ５１１およびアプリケーションプロセッサ５１２がA-PHYにより直接的に（後述する図４０を参照して説明するようなSerDes装置を介さずに）接続される直結構成となっている。
　イメージセンサ５１１は、A-PHY処理部５２１、CSIA処理部５２２、CSI2処理部５２３、CSI2-FS処理部５２４、CCI処理部５２５、CCI-FS処理部５２６、およびレジスタ５２７を備えて構成される。
　A-PHY処理部５２１は、CCI処理部５２５が上位層として実装され、アプリケーションプロセッサ５１２のA-PHY処理部５３１と、MIPI A-PHY接続して拡張パケットヘッダePHおよび拡張パケットフッタePFを含むデータを送受信する。
　CCI-FS処理部５２６は、例えば、拡張パケットヘッダePHに含まれるDesination IDとイメージセンサ５１１が有するID(Source ID)とを比較し、イメージセンサ５１１へのアクセスか否かの判別を行う。
　アプリケーションプロセッサ５１２は、A-PHY処理部５３１、CSIA処理部５３２、CSI2処理部５３３、CSI2-FS処理部５３４、CCI処理部５３５、CCI-FS処理部５３６、レジスタ５３７、およびCCI-FSスイッチ５３８を備えて構成される。
　A-PHY処理部５３１は、CCI処理部５３５が上位層として実装され、イメージセンサ５１１のA-PHY処理部５２１と、MIPI A-PHY接続して拡張パケットヘッダePHおよび拡張パケットフッタePFを含むデータを送受信する。
　CCI-FS処理部５３６は、例えば、拡張パケットヘッダePHに含まれるDesination IDとアプリケーションプロセッサ５１２が有するID(Source ID)とを比較し、アプリケーションプロセッサ５１２へのアクセスか否かの判別を行う。
　CCI-FSスイッチ５３８は、CCI-FS処理部５３６が有効である場合にはCCI-FS処理部５３６を介してデータが送受信され、CCI-FS処理部５３６が無効である場合にはCCI-FS処理部５３６を介さずにデータが送受信されるような切り替えを行う。
　図２８乃至図３２を参照して、通信システム５０１におけるリードコマンドおよびリードデータの転送について説明する。
　図２８には、リードアクセス時に、アプリケーションプロセッサ５１２のCCI-FS処理部５３６において生成されるリードコマンドのパケット構成の一例が示されている。
　図２８に示すように、リードコマンドは、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0から構成される。
　拡張パケットヘッダePH*(*=n)は、図示するように、拡張パケットヘッダePH0乃至ePH3からなる。
　拡張パケットヘッダePH0には、拡張VC、拡張DT、拡張PFEN、および拡張PHENが格納される。例えば、拡張DTは、CCIプロトコル（I2C）を示す情報であって、拡張DTを用いてルーティングの処理が行われる。
　拡張パケットヘッダePH1には、Source ID[7:1]、およびPacket Lengthが格納される。例えば、Source IDは、CCIプロトコル(I2C)の送信元を示す情報であって、Source IDに基づいて応答処理が行われる。Packet Lengthは、データ長を示す情報である。
　拡張パケットヘッダePH2には、Security Descriptor、およびMessage Counterが格納される。Security Descriptorは、セキュリティを使用するか否かを示し、セキュリティを使用しない場合には「8'h0」を示す。Message Counterは、バケット順番を示す情報であって、メッセージをカウントしたカウント値を示し、メッセージが５番目のときには「16'h5」を示す。
　拡張パケットヘッダePH3には、Destination ID[7:1]、Read/Write、およびDestinationAddressが格納される。Destination ID[7:1]は、イメージセンサ５１１のCCI処理部５２５のスレーブアドレスを示し、図示する例では「7'h0D」となっている。例えば、Destination IDは、CCIプロトコル(I2C)の送信先を示す情報であって、Destination IDに基づいてルーティングが行われるとともに、通信経路の参照が行われる。Read/Writeは、データの読み出しまたは書き込みを示し、リードの場合には「1'b1」を示す。Destination Addressは、最終目的地となるイメージセンサ５１１のレジスタ５２７のアドレスを示し、図示する例では「0x0200」となっている。
　AP(CCI)ペイロードには、例えば、各種のデータ（Data0[7:0]）が格納される。AP(CCI)ペイロードは、セキュリティがオフのときには送信されず、セキュリティがオンのとき、ダミーデータを格納して送信してもよい。
　拡張パケットフッタePF1は、セキュリティがオフのときには送信されない。
　拡張パケットフッタePF0には、CRC計算値が格納される。
　アプリケーションプロセッサ５１２では、このようなパケット構造のリードコマンドが、CCI-FS処理部５３６において生成されてA-PHY処理部５３１に供給される。
　図２９には、リードアクセス時に、アプリケーションプロセッサ５１２のA-PHY処理部５３１から出力されるリードコマンドのパケット構成の一例が示されている。
　図２９に示すように、A-PHY処理部５３１は、CCI-FS処理部５３６から供給されたリードコマンドをE2E Protectionの保護範囲として、A-PHYヘッダおよびA-PHYフッタを付加する。
　このようなパケット構造のリードコマンドが、アプリケーションプロセッサ５１２のAPHY処理部５３１によってA-PHY転送される。そして、イメージセンサ５１１では、A-PHY処理部５２１が、リードコマンドからA-PHYヘッダおよびA-PHYフッタを除去する。その後、リードコマンドは、Destination IDにより示されるスレーブアドレス「7'h0D」のCCI処理部５２５を介して、CCI-FS処理部５２６に供給される。
　図３０には、リードアクセス時に、CCI-FS処理部５２６に供給されるリードコマンドと、CCI-FS処理部５２６において生成されるリードデータのパケット構造の一例が示されている。
　図３０に示すように、図２８に示したパケット構造のままのリードコマンド、即ち、APHY転送においてE2E Protectionの保護範囲とされたリードコマンドが、CCI-FS処理部５２６に供給される。
　リードデータは、図示するように、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0から構成される。そして、AP(CCI)ペイロードには、リードコマンドの拡張パケットヘッダePHのソースアドレス情報（Destination Address）で示されるレジスタ５２７のアドレス「0x0200」から読み出されたリードデータ値が格納される。
　イメージセンサ５１１では、このようなパケット構造のリードデータが、CCI-FS処理部５２６において生成されA-PHY処理部５２１に供給される。
　図３１には、リードアクセス時に、イメージセンサ５１１のA-PHY処理部５２１から出力されるリードデータのパケット構成の一例が示されている。
　図３１に示すように、A-PHY処理部５２１は、CCI-FS処理部５２６から供給されたリードデータをE2E Protectionの保護範囲として、A-PHYヘッダおよびA-PHYフッタを付加する。
　このようなパケット構造のリードデータが、イメージセンサ５１１のA-PHY処理部５２１によってA-PHY転送される。そして、アプリケーションプロセッサ５１２では、A-PHY処理部５３１が、リードデータからA-PHYヘッダおよびA-PHYフッタを除去し、リードデータが、CCI-FS処理部５３６に供給される。
　図３２には、リードアクセス時に、CCI-FS処理部５３６に供給されるリードデータのパケット構造の一例が示されている。
　図３２に示すように、図３０に示したパケット構造のままのリードデータ、即ち、A-PHY転送においてE2E Protectionの保護範囲とされたリードデータが、CCI-FS処理部５３６に供給される。
　図３３乃至図３５を参照して、通信システム５０１におけるライトデータの転送について説明する。なお、イメージセンサ５１１側のCCI-FS処理部５２６が、イネーブルとされている状態からのアクセスを想定して説明を行う。
　図３３には、ライトアクセス時に、アプリケーションプロセッサ５１２のCCI-FS処理部５３６において生成されるライトデータのパケット構成の一例が示されている。
　図３３に示すように、ライトデータは、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード（ライトデータ）、拡張パケットフッタePF1、および拡張パケットフッタePF0から構成される。
　拡張パケットヘッダePH*(*=n)は、図示するように、拡張パケットヘッダePH0乃至ePH3からなる。
　拡張パケットヘッダePH0には、拡張VC、拡張DT、拡張PFEN、および拡張PHENが格納される。
　拡張パケットヘッダePH1には、Source ID[7:1]、およびPacket Lengthが格納される。
　拡張パケットヘッダePH2には、Security Descriptor、およびMessage Counterが格納される。Security Descriptorは、セキュリティを使用するか否かを示し、セキュリティを使用しない場合には「8'h0」を示す。Message Counterは、メッセージをカウントしたカウント値を示し、メッセージが４番目のときには「16'h4」を示す。
　拡張パケットヘッダePH3には、Destination ID[7:1]、Read/Write、およびDestinationAddressが格納される。Destination ID[7:1]は、イメージセンサ５１１のCCI処理部５２５のスレーブアドレスを示し、図示する例では「7'h0D」となっている。Read/Writeは、データの読み出しまたは書き込みを示し、ライトの場合には「1'b0」を示す。Destination Addressは、最終目的地となるイメージセンサ５１１のレジスタ５２７のアドレスを示し、図示する例では「0x1234」となっている。
　AP(CCI)ペイロードには、イメージセンサ５１１に書き込むデータ（Data0[7:0]）が格納され、0xFF値がライトデータとなる。
　拡張パケットフッタePF1は、セキュリティがオフのときには送信されない。
　拡張パケットフッタePF0には、CRC計算値が格納される。
　アプリケーションプロセッサ５１２では、このようなパケット構造のライトデータが、CCI-FS処理部５３６において生成されてA-PHY処理部５３１に供給される。
　図３４には、ライトアクセス時に、アプリケーションプロセッサ５１２のA-PHY処理部５３１から出力されるライトデータのパケット構成の一例が示されている。
　図３４に示すように、A-PHY処理部５３１は、CCI-FS処理部５３６から供給されたライトデータをE2E Protectionの保護範囲として、A-PHYヘッダおよびA-PHYフッタを付加する。
　このようなパケット構造のライトデータが、アプリケーションプロセッサ５１２のA-PHY処理部５３１によってA-PHY転送される。そして、イメージセンサ５１１では、A-PHY処理部５２１が、ライトデータからA-PHYヘッダおよびA-PHYフッタを除去する。その後、ライトデータは、Destination IDにより示されるスレーブアドレス「7'h0D」のCCI処理部５２５を介して、CCI-FS処理部５２６に供給される。
　図３５には、ライトアクセス時に、CCI-FS処理部５２６に供給されるライトデータのパケット構造の一例が示されている。
　図３５に示すように、図３３に示したパケット構造のままのライトデータ、即ち、A-PHY転送においてE2E Protectionの保護範囲とされたライトデータが、CCI-FS処理部５２６に供給される。そして、CCI-FS処理部５２６は、CCIコマンドID情報、即ち、リードコマンドの拡張パケットヘッダePHのソースアドレス情報（Destination Address）で示されるレジスタ５２７のアドレス「0x1234」より、AP(CCI)ペイロードに格納されているデータの書き込みを行う。
　図３６を参照して、拡張パケットヘッダePHおよび拡張パケットフッタePFの概要について説明する。
　図３６に示すように、CCI-FS E2Eパケットは、拡張パケットヘッダePH、パケットデータ、および拡張パケットフッタePFにより構成され、そのパケット長は、Length = Byte Count × Data Byte widthとなる。
　拡張パケットヘッダePHは、拡張VC、拡張DT、Message Counterなどのフィールドが用いられる。拡張パケットヘッダePHのフィールド値（epFEN field）で、拡張パケットヘッダePHの長さを変更することができる。
　パケットデータは、例えば、PL個のデータ（Data 0～ata PL-1）により構成され、その長さは、Length = Packet Length(PL) × Data Byte Widthとなる。パケットデータには、リードコマンドの場合に、セキュリティがオフのときにはデータが格納されず、セキュリティがオンのときには１バイトのダミーデータが格納される。パケットデータには、ライトアクセスの場合に、ペイロードデータ分のライトデータが格納される。パケットデータには、リードアクセスの場合は、ペイロードデータ分のリードデータが格納される。パケットデータには、Clock Stretch（ePH0のControl Code Indicator=1）を用いるときは、制御の種類を意味する１バイトのデータペイロードが付けられる。
　拡張パケットフッタePF1は、拡張パケットヘッダePHのフィールド設定値（epFEN field）で、長さを変更することができる。また、セキュリティ関連情報を付加することができる。
　拡張パケットフッタePF0は、拡張パケットヘッダePHのフィールド設定値で、パケットデータから計算されるCRC-32を付加することができる。
　＜通信処理の処理例＞
　図３７乃至図３９のフローチャートを参照して、図２７に示した通信システム５０１において行われるCCI-FSを使用した通信処理について説明する。
　図３７に示すように、ステップＳ２１１乃至Ｓ２２２では、初期設定および確認動作が行われる。
　ステップＳ２１１において、アプリケーションプロセッサ５１２からイメージセンサ５１１へ、CCI-FS処理部５２６のCapabilityレジスタに対して２回リードアクセスが行われる。なお、リードアクセスを行う回数は２回に限定されることなく、例えば、機能安全的に任意に設定することができ、１回または３回以上の複数回でもよい。
　ステップＳ２１２において、アプリケーションプロセッサ５１２では、CSI2-FS処理部５２４が、ステップＳ２１１でのリードアクセスの結果について、CCI-FS処理部５２６のCapabilityレジスタ値が２回とも1’b1であるか否かを判定する。ステップＳ２１２において、CCI-FS処理部５２６のCapabilityレジスタ値が２回とも1’b1でないと判定された場合、処理はステップＳ２１３に進む。
　ステップＳ２１３において、アプリケーションプロセッサ５１２では、CSI2-FS処理部５２４が、再送回数が３回以上であるか否かを判定する。なお、再送回数は３回に限定されることなく、任意の回数に設定することができ、以下で説明する再送回数についても同様である。ステップＳ２１３において、再送回数が３回以上でない（１回または２回）と判定された場合、処理はステップＳ２１１に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ２１２において、CCI-FS処理部５２６のCapabilityレジスタ値が２回とも1’b1であると判定された場合、処理は２１４に進む。
　ステップＳ２１４において、アプリケーションプロセッサ５１２からイメージセンサ５１１へ、CCI-FS処理部５２６のEnableレジスタに対する１ライトアクセスが行われる。
　ステップＳ２１５において、イメージセンサ５１１では、CCI-FS処理部５２６が、アプリケーションプロセッサ５１２のCCI-FS処理部５３６のEnableレジスタに対する１ライトアクセスを行う。
　ステップＳ２１６において、アプリケーションプロセッサ５１２のCCI-FS処理部５３６のDestination SIDレジスタに、対向のイメージセンサ５１１のスレーブアドレスを設定する。
　ステップＳ２１７において、アプリケーションプロセッサ５１２のCCI-FS処理部５３６のePHレジスタの設定を行う。
　ステップＳ２１８において、アプリケーションプロセッサ５１２からイメージセンサ５１１へ、CCI-FS処理部５２６のePHレジスタの設定が行われる。
　ステップＳ２１９において、アプリケーションプロセッサ５１２からイメージセンサ５１１へ、CCI-FS処理部５２６のEnableレジスタおよびErrorレジスタに対するリードアクセスが行われる。
　ステップＳ２２０において、アプリケーションプロセッサ５１２では、CCI-FS処理部５３６が、ステップＳ２１９でのリードアクセスの結果について、CCI-FS処理部５２６のEnableレジスタ値が1’b1であり、かつ、Errorレジスタ値が０であるか否かを判定する。
　ステップＳ２２０において、CCI-FS処理部５２６のEnableレジスタ値が1’b1でない、または、Errorレジスタ値が０でないと判定された場合、処理はステップＳ２２１に進む。
　ステップＳ２２１において、アプリケーションプロセッサ５１２では、CSI2-FS処理部５２４が、再送回数が３回以上であるか否かを判定する。ステップＳ２２１において、再送回数が３回以上であると判定された場合、処理はステップＳ２１１に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ２１３において、再送回数が３回以上であると判定された場合、または、ステップＳ２２１において、再送回数が３回以上でない（１回または２回）と判定された場合、処理はステップＳ２２２に進む。
　ステップＳ２２２において、CCI-FSを使用せずにCCIでの通信を行い、その後、通信処理が終了される。
　一方、ステップＳ２２０において、CCI-FS処理部５２６のEnableレジスタ値が1’b1であり、かつ、Errorレジスタ値が０であると判定された場合、処理はステップＳ２２３に進む。
　図３８に示すように、ステップＳ２２３乃至Ｓ２３４では、CCI-FSを使用したライト動作が行われる。
　ステップＳ２２３において、アプリケーションプロセッサ５１２のCCI-FS処理部５３６は、ライト動作を行うようにePHレジスタの設定を行う。
　ステップＳ２２４において、アプリケーションプロセッサ５１２のCCI-FS処理部５３６は、ライトデータレジスタの設定を行う。
　ステップＳ２２５において、アプリケーションプロセッサ５１２のCCI-FS処理部５３６は、コマンド実行レジスタを１に設定する。
　ステップＳ２２６において、アプリケーションプロセッサ５１２では、A-PHY処理部５３１が、上述した図３４に示したように、CCI-FS処理部５３６により生成されたライトデータをE2E Protectionの保護範囲として、A-PHYヘッダおよびA-PHYフッタを付加し、A-PHY転送を行う。
　ステップＳ２２７において、イメージセンサ５１１では、A-PHY処理部５２１が、ライトデータからA-PHYヘッダおよびA-PHYフッタを除去し、E2E Protectionの保護範囲をCCIFS処理部５２６に供給する。
　ステップＳ２２８において、イメージセンサ５１１では、CCI-FS処理部５２６が、拡張パケットヘッダePHの内容から、イメージセンサ５１１のSource IDと、拡張パケットヘッダePHのDestination SIDとを確認する。
　ステップＳ２２９において、イメージセンサ５１１では、CCI-FS処理部５２６が、ステップＳ２２８で確認したイメージセンサ５１１のSource IDと拡張パケットヘッダePHのDestination SIDとが一致したか否かを判定する。
　ステップＳ２２９において、イメージセンサ５１１のSource IDと拡張パケットヘッダePHのDestination SIDとが一致したと判定された場合、処理はステップＳ２３０に進む。
　ステップＳ２３０において、イメージセンサ５１１では、CCI-FS処理部５２６が、拡張パケットヘッダePHの内容から、Message Counterを確認する。
　ステップＳ２３１において、イメージセンサ５１１では、CCI-FS処理部５２６が、ステップＳ２３０で確認したイメージセンサ５１１のMessage Counter（受信）と、拡張パケットヘッダePHのMessage Counterとが一致したか否かを判定する。
　ステップＳ２３１において、イメージセンサ５１１のMessage Counter（受信）と拡張パケットヘッダePHのMessage Counterとが一致したと判定された場合、処理はステップＳ２３２に進む。
　ステップＳ２３２において、イメージセンサ５１１では、CCI-FS処理部５２６が、拡張パケットフッタePFの内容から、CRCを確認する。
　ステップＳ２３３において、イメージセンサ５１１では、CCI-FS処理部５２６が、ステップＳ２３２で確認した拡張パケットフッタePFの受信値（ePF0）と、CCI-FS処理部５２６において計算されたCRC計算結果が一致したか否かを判定する。
　ステップＳ２３３において、拡張パケットフッタePFの受信値（ePF0）とCRC計算結果とが一致したと判定された場合、処理はステップＳ２３４に進む。
　ステップＳ２３４において、イメージセンサ５１１では、CCI-FS処理部５２６が、拡張パケットヘッダePHおよび拡張パケットフッタePFの内容から、レジスタ５２７のアドレスにライトデータを書き込むライト処理を行う。その後、処理はステップＳ２３５に進む。
　図３９に示すように、ステップＳ２３５乃至Ｓ２４７では、CCI-FSを使用したリード動作が行われる。
　ステップＳ２３５において、アプリケーションプロセッサ５１２では、CCI-FS処理部５３６が、リード動作が行われるようにePHレジスタの設定を行う。
　ステップＳ２３６において、アプリケーションプロセッサ５１２では、CCI-FS処理部５３６が、コマンド実行レジスタを１に設定する。
　ステップＳ２３７において、アプリケーションプロセッサ５１２では、A-PHY処理部５３１が、上述した図２９に示したように、CCI-FS処理部５３６により生成されたライトデータをE2E Protectionの保護範囲として、A-PHYヘッダおよびA-PHYフッタを付加し、A-PHY転送を行う。
　ステップＳ２３８において、イメージセンサ５１１では、A-PHY処理部５２１が、ライトデータからA-PHYヘッダおよびA-PHYフッタを除去し、E2E Protectionの保護範囲をCCI-FS処理部５２６に供給する。
　ステップＳ２３９において、イメージセンサ５１１では、CCI-FS処理部５２６が、拡張パケットヘッダePHの内容から、イメージセンサ５１１のSource IDと、拡張パケットヘッダePHのDestination SIDとを確認する。
　ステップＳ２４０において、イメージセンサ５１１では、CCI-FS処理部５２６が、ステップＳ２３９で確認したイメージセンサ５１１のSource IDと拡張パケットヘッダePHのDestination SIDとが一致したか否かを判定する。
　ステップＳ２４０において、イメージセンサ５１１のSource IDと拡張パケットヘッダePHのDestination SIDとが一致したと判定された場合、処理はステップＳ２４１に進む。
　ステップＳ２４１において、イメージセンサ５１１では、CCI-FS処理部５２６が、拡張パケットヘッダePHの内容から、Message Counterを確認する。
　ステップＳ２４２において、イメージセンサ５１１では、CCI-FS処理部５２６が、ステップＳ２４１で確認したイメージセンサ５１１のMessage Counter（受信）と、拡張パケットヘッダePHのMessage Counterとが一致したか否かを判定する。
　ステップＳ２４２において、イメージセンサ５１１のMessage Counter（受信）と拡張パケットヘッダePHのMessage Counterとが一致したと判定された場合、処理はステップＳ２４３に進む。
　ステップＳ２４３において、イメージセンサ５１１では、CCI-FS処理部５２６が、拡張パケットフッタePFの内容から、CRCを確認する。
　ステップＳ２４４において、イメージセンサ５１１では、CCI-FS処理部５２６が、ステップＳ２４３で確認した拡張パケットフッタePFの受信値（ePF0）と、CCI-FS処理部５２６において計算されたCRC計算結果が一致したか否かを判定する。
　ステップＳ２４４において、拡張パケットフッタePFの受信値（ePF0）とCRC計算結果とが一致したと判定された場合、処理は終了される。
　一方、図３８のステップＳ２２９または図３９のステップＳ２４０で、イメージセンサ５１１のSource IDと拡張パケットヘッダePHのDestination SIDとが一致していないと判定された場合、処理はステップＳ２４５に進む。
　ステップＳ２４５において、イメージセンサ５１１側のErrorレジスタ（Routing）を１とし、その後、処理は終了される。
　一方、図３８のステップＳ２３１または図３９のステップＳ２４２で、イメージセンサ５１１のMessage Counter（受信）と拡張パケットヘッダePHのMessage Counterとが一致していないと判定された場合、処理はステップＳ２４６に進む。
　ステップＳ２４６において、イメージセンサ５１１側のErrorレジスタ（MC）を１とし、その後、処理は終了される。
　一方、図３８のステップＳ２３３または図３９のステップＳ２４４で、拡張パケットフッタePFの受信値（ePF0）とCRC計算結果とが一致していないと判定された場合、処理はステップＳ２４７に進む。
　ステップＳ２４７において、イメージセンサ５１１側のErrorレジスタ（CRC）を１とし、その後、処理は終了される。
　＜SerDes接続構成の構成例＞
　図４０に示す通信システム６０１は、イメージセンサ６１１およびアプリケーションプロセッサ６１４が、スレーブ側となるSerDes装置６１２とマスタ側となるSerDes装置６１３とを介して接続されるSerDes接続構成となっている。
　イメージセンサ６１１は、I2C/I3Cスレーブ６２１、CCI処理部６２２、CSI2-FS処理部６２３、およびレジスタ６２４を備えて構成される。
　スレーブ側のSerDes装置６１２は、A-PHY処理部６３１、CSIA処理部６３２、CSI2-FS処理部６３３、I2C/I3Cマスタ６３４、CCI処理部６３５、CCI-FS処理部６３６、およびレジスタ６３７を備えて構成される。
　マスタ側のSerDes装置６１３は、A-PHY処理部６４１、CSIA処理部６４２、CSI2-FS処理部６４３、I2C/I3Cスレーブ６４４、CCI処理部６４５、CCI-FS処理部６４６、およびレジスタ６４７を備えて構成される。
　アプリケーションプロセッサ６１４は、I2C/I3Cマスタ６５１、CCI処理部６５２、CCIFS処理部６５３、レジスタ６５４、およびCCI-FSスイッチ６５５を備えて構成される。
　なお、図４０に示すようなSerDes接続構成では、CCI構成やCCI-FS構成が上位プロトコルとして実装されている場合、他のSerDes規格を使用してもよい。例えば、ApplicationLayer、または、その下のレイヤに相当する上位層からのPayloadに、図４１に示すような拡張パケットヘッダePH、拡張パケットフッタePF1、および拡張パケットフッタePF0の構成を実装することにより、PCIE，USB，DisplayPort，HDMI（登録商標），LVDS，FPD-LINKなどの各種のSerDes関連を適用することができる。
　図４１乃至図４９を参照して、通信システム６０１におけるリードコマンドおよびリードデータの転送について説明する。
　図４１には、リードアクセス時に、アプリケーションプロセッサ６１４のCCI-FS処理部６５３において生成されるリードコマンドのパケット構成の一例が示されている。
　図４１に示すように、リードコマンドは、拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0から構成される。なお、それらの詳細については、上述の図２８を参照して説明したリードコマンドと同様である。
　アプリケーションプロセッサ６１４では、このようなパケット構造のリードコマンドが、CCI-FS処理部６５３において生成されてI2C/I3Cマスタ６５１に供給される。
　図４２には、リードアクセス時に、アプリケーションプロセッサ６１４のI2C/I3Cマスタ６５１から出力されるリードコマンドのパケット構成の一例が示されている。
　図４２に示すように、I2C/I3Cマスタ６５１は、スタートコンディションＳに続けて、接続先のセンサアドレス、即ち、図４０に示す構成ではマスタ側のSerDes装置６１３のCCI処理部６４５のアドレス（Slave Address+W 8-bit）を送信する。図４２に示す例では、CCI処理部６４５のアドレスは、Slave Address[7:1]=7'h0Fとなっている。そのアドレスに続いて、マスタ側のSerDes装置６１３のレジスタ６４７のレジスタアドレス（RegisterAddress [15:8]およびRegister Address [7:0]）が送信される。I2C/I3Cマスタ６５１は、拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0に続けて、最後にストップコンディションＰを送信する。
　このようなパケット構造のリードコマンドが、アプリケーションプロセッサ６１４のI2C/I3Cマスタ６５１からI2C/I3Cにより転送される。マスタ側のSerDes装置６１３では、I2C/I3Cスレーブ６４４が、リードコマンド（拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0）を取得する。そのリードコマンドは、Slave Address[7:1]=7'h0FのCCI処理部６４５に供給された後、CCI-FS処理部６４６、CSI2-FS処理部６４３、およびCSIA処理部６４２を介して、A-PHY処理部６４１に供給される。
　図４３には、リードアクセス時に、マスタ側のSerDes装置６１３のA-PHY処理部６４１から出力されるリードコマンドのパケット構成の一例が示されている。
　図４３に示すように、A-PHY処理部６４１は、I2C/I3Cスレーブ６４４が取得したリードコマンドをE2E Protectionの保護範囲として、A-PHYヘッダおよびA-PHYフッタを付加する。なお、拡張パケットヘッダePH*(*=n)には、マスタ側のSerDes装置６１３のCCI処理部６３５のアドレス、例えば、Slave Address[7:1]=7'h0Eが、CSI2-FS処理部６４３において付加される。
　このようなパケット構造のリードコマンドが、マスタ側のSerDes装置６１３のA-PHY処理部６４１によってA-PHY転送される。スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、リードコマンドからA-PHYヘッダおよびA-PHYフッタを除去する。リードコマンドは、CSIA処理部６３２、CSI2-FS処理部６３３、CCI-FS処理部６３６を介して、Destination IDにより示されるスレーブアドレス「7'h0E」のCCI処理部６３５に供給された後、I2C/I3Cマスタ６３４に供給される。
　図４４には、リードアクセス時に、I2C/I3Cマスタ６３４から出力されるリードコマンドのパケット構成の一例が示されている。
　図４４に示すように、I2C/I3Cマスタ６３４は、スタートコンディションＳに続けて、接続先のセンサアドレス、即ち、図４０に示す構成ではイメージセンサ６１１のCCI処理部６２２のアドレス（Slave Address+W 8-bit）を送信する。図４４に示す例では、CCI処理部６２２のアドレスは、Slave Address[7:1]=7'h0Dとなっている。そのアドレスに続いて、イメージセンサ６１１のレジスタ６２４のレジスタアドレス（Register Address [15:8]およびRegister Address [7:0]）が送信される。I2C/I3Cマスタ６３４は、拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0に続けて、最後にストップコンディションＰを送信する。
　このようなパケット構造のリードコマンドが、スレーブ側のSerDes装置６１２のI2C/I3Cマスタ６３４からI2C/I3Cにより転送される。そして、イメージセンサ６１１では、I2C/I3Cスレーブ６２１がリードコマンド（拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0）を取得する。そのリードコマンドは、Slave Address[7:1]=7'h0DのCCI処理部６２２を介して、CSI2-FS処理部６２３に供給される。
　図４５には、リードアクセス時に、CSI2-FS処理部６２３に供給されるリードコマンドと、CSI2-FS処理部６２３において生成されるリードデータのパケット構造の一例が示されている。
　図４５に示すように、図４１に示したパケット構造のままのリードコマンド、即ち、APHY転送においてE2E Protectionの保護範囲とされたリードコマンドが、CSI2-FS処理部６２３に供給される。
　リードデータは、図示するように、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0から構成される。そして、AP(CCI)ペイロードには、リードコマンドの拡張パケットヘッダePHのソースアドレス情報（Destination Address）で示されるレジスタ６２４のアドレス「0x0200」から読み出されたリードデータ値が格納される。
　イメージセンサ６１１では、このようなパケット構造のリードデータが、CCI-FS処理部６２３において生成され、CCI処理部６２２を介してI2C/I3Cスレーブ６２１に供給される。
　図４６には、リードアクセス時に、イメージセンサ６１１のI2C/I3Cスレーブ６２１から出力されるリードデータのパケット構成の一例が示されている。
　図４６に示すように、I2C/I3Cスレーブ６２１は、スタートコンディションＳに続けて、接続先のセンサアドレス、即ち、図４０に示す構成ではスレーブ側のSerDes装置６１２のI2C/I3Cマスタ６３４のアドレス（Slave Address+W 8-bit）を送信する。図４６に示す例では、I2C/I3Cマスタ６３４のアドレスは、Slave Address[7:1]=7'h0Dとなっている。そのアドレスに続いて、リードデータの格納アドレス（イメージセンサ６１１のレジスタ６２４のアドレス）が送信され、スレーブ側のSerDes装置６１２のI2C/I3Cマスタ６３４のアドレス（Slave Address+R 8-bit）が送信される。I2C/I3Cスレーブ６２１が、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0を送信した後、最後にストップコンディションＰが送信される。
　このようなパケット構造のリードコマンドが、イメージセンサ６１１のI2C/I3Cスレーブ６２１からからI2C/I3Cにより転送される。スレーブ側のSerDes装置６１２では、I2C/I3Cマスタ６３４が、リードデータ（拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0）を取得する。そのリードデータは、Slave Address[7:1]=7'h0EのCCI処理部６３５に供給された後、CCI-FS処理部６３６、CSI2-FS処理部６３３、およびCSIA処理部６３２を介して、A-PHY処理部６３１に供給される。
　図４７には、リードアクセス時に、スレーブ側のSerDes装置６１２のA-PHY処理部６３１から出力されるリードデータのパケット構成の一例が示されている。
　図４７に示すように、A-PHY処理部６３１は、I2C/I3Cマスタ６３４が取得したリードデータをE2E Protectionの保護範囲として、A-PHYヘッダおよびA-PHYフッタを付加する。
　このようなパケット構造のリードデータが、スレーブ側のSerDes装置６１２のA-PHY処理部６３１によってA-PHY転送される。そして、マスタ側のSerDes装置６１３では、A-PHY処理部６４１が、リードデータからA-PHYヘッダおよびA-PHYフッタを除去する。リードデータは、CSIA処理部６４２、CSI2-FS処理部６４３、CCI-FS処理部６４６、およびCCI処理部６３５を介して、I2C/I3Cスレーブ６４４に供給される。
　図４８には、リードアクセス時に、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４から出力されるリードデータのパケット構成の一例が示されている。
　図４８に示すように、I2C/I3Cスレーブ６４４は、スタートコンディションＳに続けて、接続先のセンサアドレス、即ち、図４０に示す構成では、マスタ側のSerDes装置６１３のCCI処理部６３５のアドレス（Slave Address+W 8-bit）を送信する。図４８に示す例では、CCI処理部６３５のアドレスは、Slave Address[7:1]=7'h0Fとなっている。そのアドレスに続いて、マスタ側のSerDes装置６１３のレジスタ６４７のレジスタアドレス（Register Address [15:8]およびRegister Address [7:0]）が送信され、CCI処理部６３５のアドレス（Slave Address+R 8-bit）が送信される。続いて、I2C/I3Cスレーブ６４４が、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0を送信した後、最後にストップコンディションＰが送信される。
　このようなパケット構造のリードデータが、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からI2C/I3Cにより転送される。そして、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、リードコマンド（拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0）を取得して、CCI-FS処理部６５３に供給する。
　図４９には、リードアクセス時に、CCI-FS処理部６５３に供給されるリードデータのパケット構造の一例が示されている。
　図４９に示すように、図４５に示したパケット構造のままのリードデータ、即ち、A-PHY転送においてE2E Protectionの保護範囲とされたリードデータが、CCI-FS処理部６５３に供給される。
　＜通信処理の処理例＞
　図５０乃至図５７のフローチャートを参照して、図４０に示した通信システム６０１において行われるCCI-FSを使用した通信処理について説明する。
　図５０に示すように、ステップＳ３０１乃至Ｓ３１７では、初期設定および確認動作が行われる。
　ステップＳ３０１において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３のDestination SIDレジスタに、対向のイメージセンサ６１１のスレーブアドレスを設定する。
　ステップＳ３０２において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３のePHレジスタの設定を行う。
　ステップＳ３０３において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３のBridge構成のDestination SIDの設定を行い、マスタ側のSerDes装置６１３を登録する。ここで、Address，attribution，Timeout_no1レジスタも、これと同様に設定を行い、以下、同様に設定が行われるものとする。
　ステップＳ３０４において、アプリケーションプロセッサ６１４からマスタ側のSerDes装置６１３へ、CCI-FS処理部６４３のePHレジスタの設定が行われる。
　ステップＳ３０５において、アプリケーションプロセッサ６１４からマスタ側のSerDes装置６１３へ、CCI-FS処理部６４３のBridge構成のDestination SIDの設定を行い、スレーブ側のSerDes装置６１２を登録する。
　ステップＳ３０６において、アプリケーションプロセッサ６１４からマスタ側のSerDes装置６１３へ、CCI-FS処理部６４３のErrorレジスタに対するリードアクセスが行われる。
　ステップＳ３０７において、アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、ステップＳ３０６のリードアクセスの結果、マスタ側のSerDes装置６１３のCCIFS処理部６４３のErrorレジスタのレジスタ値が０であるか否かを判定する。
　ステップＳ３０７において、マスタ側のSerDes装置６１３のCCI-FS処理部６４３のErrorレジスタのレジスタ値が０でない（０以外である）と判定された場合、処理はステップＳ３０８に進む。
　ステップＳ３０８において、アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、再送回数が３回以上であるか否かを判定し、再送回数が３回以上でない（１回または２回）と判定した場合、処理はステップＳ３０４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ３０７において、マスタ側のSerDes装置６１３のCCI-FS処理部６４３のErrorレジスタのレジスタ値が０であると判定された場合、処理はステップＳ３０９に進む。
　ステップＳ３０９において、アプリケーションプロセッサ６１４からスレーブ側のSerDes装置６１２へ、CCI-FS処理部６３６のePHレジスタの設定が行われる。
　ステップＳ３１０において、アプリケーションプロセッサ６１４からスレーブ側のSerDes装置６１２へ、CCI-FS処理部６３６のBridge構成のDestination SIDの設定を行い、スレーブ側のSerDes装置６１２を登録する。
　ステップＳ３１１において、アプリケーションプロセッサ６１４からスレーブ側のSerDes装置６１２へ、CCI-FS処理部６３６のErrorレジスタに対するリードアクセスが行われる。
　ステップＳ３１２において、アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、ステップＳ３１１のリードアクセスの結果、スレーブ側のSerDes装置６１２のCCI-FS処理部６３６のErrorレジスタのレジスタ値が０であるか否かを判定する。
　ステップＳ３１２において、スレーブ側のSerDes装置６１２のCCI-FS処理部６３６のErrorレジスタのレジスタ値が０でない（０以外である）と判定された場合、処理はステップＳ３１３に進む。
　ステップＳ３１３において、アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、再送回数が３回以上であるか否かを判定し、再送回数が３回以上でない（１回または２回）と判定した場合、処理はステップＳ３０９に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ３１２において、スレーブ側のSerDes装置６１２のCCI-FS処理部６３６のErrorレジスタのレジスタ値が０であると判定された場合、処理はステップＳ３１４に進む。
　ステップＳ３１４において、アプリケーションプロセッサ６１４からイメージセンサ６１１へ、CCI-FS処理部６２３のePHレジスタの設定が行われる。
　ステップＳ３１５において、アプリケーションプロセッサ６１４からイメージセンサ６１１へ、CCI-FS処理部６２３のErrorレジスタに対するリードアクセスが行われる。
　ステップＳ３１６において、アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、ステップＳ３１５のリードアクセスの結果、イメージセンサ６１１のCCI-FS処理部６２３のErrorレジスタのレジスタ値が０であるか否かを判定する。
　ステップＳ３１６において、イメージセンサ６１１のCCI-FS処理部６２３のErrorレジスタのレジスタ値が０でない（０以外である）と判定された場合、処理はステップＳ３１７に進む。
　ステップＳ３１７において、アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、再送回数が３回以上であるか否かを判定し、再送回数が３回以上でない（１回または２回）と判定した場合、処理はステップＳ３１４に戻り、以下、同様の処理が繰り返して行われる。
　ここで、ステップＳ３０８、ステップＳ３１３、またはステップＳ３１７において、再送回数が３回以上であると判定された場合、処理はステップＳ３０１に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ３１６において、イメージセンサ６１１のCCI-FS処理部６２３のErrorレジスタのレジスタ値が０であると判定された場合、処理はステップＳ３１８に進む。
　図５１に示すように、ステップＳ３１８乃至Ｓ３２７では、CCI-FSを使用したライト動作が行われる。
　ステップＳ３１８において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３が、ライト動作を行うようにePHレジスタの設定を行う。
　ステップＳ３１９において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３は、ライトデータレジスタの設定を行う。
　ステップＳ３２０において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３は、コマンド実行レジスタを１に設定して、ライトコマンドを発行する。
　ステップＳ３２１において、アプリケーションプロセッサ６１４は、図５３を参照して後述するSequence A_Write（AP時）処理を行う。
　ステップＳ３２２において、マスタ側のSerDes装置６１３は、図５６を参照して後述するSequence B（SerDes(Master)時）処理を行う。なお、図５６では、スレーブ側のSerDes装置６１２が実行するSequence B（SerDes(Slave)時）処理について説明しているが、マスタ側のSerDes装置６１３においても対応する各ブロックにより同様の処理を実行することができる。
　ステップＳ３２３において、マスタ側のSerDes装置６１３の拡張パケットヘッダePHの拡張DTから、CSI2-FS処理部６４３およびCSIA処理部６４２を経由して、A-PHY処理部６４１が、A-PHYヘッダおよびA-PHYフッタを付加してA-PHY転送を行う。
　ステップＳ３２４において、スレーブ側のSerDes装置６１２は、図５６を参照して後述するSequence B（SerDes(Slave)時）処理を行う。
　ステップＳ３２５において、スレーブ側のSerDes装置６１２は、図５３を参照して後述するSequence A_Write（SerDes(Slave)時）処理を行う。なお、図５３では、アプリケーションプロセッサ６１４が実行するSequence A_Write（AP時）処理について説明しているが、スレーブ側のSerDes装置６１２においても対応する各ブロックにより同様の処理を実行することができる。
　ステップＳ３２６において、イメージセンサ６１１は、図５６を参照して後述するSequence B（Image Sensor時）処理を行う。なお、図５６では、スレーブ側のSerDes装置６１２が実行するSequence B（SerDes(Slave)時）処理について説明しているが、イメージセンサ６１１においても対応する各ブロックにより同様の処理を実行することができる。
　ステップＳ３２７において、イメージセンサ６１１では、CCI-FS処理部６２３が、拡張パケットヘッダePHおよび拡張パケットフッタePFの内容から、レジスタ６２４のアドレスにライトデータを書き込むライト処理を行う。その後、処理はステップＳ３２８に進む。
　図５２に示すように、ステップＳ３２８乃至Ｓ３４４では、CCI-FSを使用したリード動作が行われる。
　ステップＳ３２８において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３は、リード動作を行うようにePHレジスタの設定を行う。
　ステップＳ３２９において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３は、リードデータレジスタの設定を行う。
　ステップＳ３３０において、アプリケーションプロセッサ６１４のCCI-FS処理部６５３は、コマンド実行レジスタを１に設定して、リードコマンドを発行する。
　ステップＳ３３１において、アプリケーションプロセッサ６１４は、図５４を参照して後述するSequence A_Read_CMD（AP時）処理を行う。ここで、Sequence A_Read_CMD（AP時）処理では、分岐された２つの処理が並列的に行われ、分岐Ａに応じてステップＳ３３２に処理は進み、分岐Ｂに応じてステップＳ３３９に処理は進む。
　ステップＳ３３２において、マスタ側のSerDes装置６１３は、図５６を参照して後述するSequence B（SerDes(Master)時）処理を行う。なお、図５６では、スレーブ側のSerDes装置６１２が実行するSequence B（SerDes(Slave)時）処理について説明しているが、マスタ側のSerDes装置６１３においても対応する各ブロックにより同様の処理を実行することができる。
　ステップＳ３３３において、マスタ側のSerDes装置６１３の拡張パケットヘッダePHの拡張DTから、CSI2-FS処理部６４３およびCSIA処理部６４２を経由して、A-PHY処理部６４１が、A-PHYヘッダおよびA-PHYフッタを付加してA-PHY転送を行う。
　ステップＳ３３４において、スレーブ側のSerDes装置６１２は、図５６を参照して後述するSequence B（SerDes(Slave)時）処理を行う。
　ステップＳ３５５において、スレーブ側のSerDes装置６１２は、図５４を参照して後述するSequence A_Read_CMD（SerDes(Slave)時）処理を行う。なお、図５４では、アプリケーションプロセッサ６１４において実行されるSequence A_Read_CMD（AP時）処理について説明しているが、スレーブ側のSerDes装置６１２においても対応する各ブロックにより同様の処理を実行することができる。ここで、Sequence A_Read_CMD（SerDes(Slave)時）処理では、分岐された２つの処理のうち、分岐Ａに処理は進まず、分岐Ｂに応じてステップＳ３３６に処理は進む。
　ステップＳ３３６において、スレーブ側のSerDes装置６１２は、図５７を参照して後述するSequence A_Read_Data（SerDes(Slave)時）処理を行う。なお、図５７では、アプリケーションプロセッサ６１４において実行されるSequence A_Read_Data（AP時）処理について説明しているが、スレーブ側のSerDes装置６１２においても対応する各ブロックにより同様の処理を実行することができる。
　ステップＳ３３７において、スレーブ側のSerDes装置６１２の拡張パケットヘッダePHの拡張DTから、CSI2-FS処理部６３３およびCSIA処理部６３２を経由して、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを付加してA-PHY転送を行う。
　ステップＳ３３８において、マスタ側のSerDes装置６１３は、図５６を参照して後述するSequence B（SerDes(Master)時）処理を行う。なお、図５６では、スレーブ側のSerDes装置６１２において実行されるSequence B（SerDes(Slave)時）処理について説明しているが、マスタ側のSerDes装置６１３においても対応する各ブロックにより同様の処理を実行することができる。
　ステップＳ３３９において、アプリケーションプロセッサ６１４は、図５７を参照して後述するSequence A_Read_Data（AP時）処理を行う。
　ステップＳ３４０において、アプリケーションプロセッサ６１４は、図５６を参照して後述するSequence B（AP時）処理を行う。なお、図５６では、スレーブ側のSerDes装置６１２において実行されるSequence B（SerDes(Slave)時）処理について説明しているが、アプリケーションプロセッサ６１４においても対応する各ブロックにより同様の処理を実行することができる。
　ステップＳ３４１において、アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、拡張パケットヘッダePHおよび拡張パケットフッタePFの内容から、レジスタ６５４のアドレスにリードデータを格納する。
　ステップＳ３４２において、上述したリード処理を、イメージセンサ６１１、スレーブ側のSerDes装置６１２、マスタ側のSerDes装置６１３、およびアプリケーションプロセッサ６１４で、Errorレジスタ確認を実施する。
　ステップＳ３４３において、イメージセンサ６１１、各デバイス（スレーブ側のSerDes装置６１２、マスタ側のSerDes装置６１３、およびアプリケーションプロセッサ６１４）は、それぞれのCCI-FS処理部のErrorレジスタのレジスタ値が０であるか否かを判定する。
　ステップＳ３４３において、全てのCCI-FS処理部のレジスタ値が０でない（いずれかに０以外のレジスタ値がある）と判定された場合、処理はステップＳ３４４に進む。
　ステップＳ３４４において、レジスタ値が０でないCCI-FS処理部のError関連レジスタ値を確認し、Errorレジスタを１ライトクリアして再送処理を行う。
　一方、ステップＳ３４３において、全てのCCI-FS処理部のレジスタ値が０であると判定された場合、または、ステップＳ３４４の処理後、処理は終了される。
　図５３は、図５１のステップＳ３２１において行われるSequence A_Write（AP時）処理を説明するフローチャートである。なお、図５３では、アプリケーションプロセッサ６１４が行う処理を例に説明するが、図５１のステップＳ３２５のSequence A_Write（SerDes(Slave)時）処理も同様に行われる。
　ステップＳ３５１において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、スタートコマンドおよびスレーブアドレス（図４２に示したSlave Address+W8-bit）を発行する。
　ステップＳ３５２において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したか否かを判定する。ステップＳ３５２において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したと判定された場合、処理はステップＳ３５３に進む。
　ステップＳ３５３において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、レジスタアドレス（図４２に示したRegister Address [15:8]）を発行する。ここで、ステップＳ３５３の処理が繰り返して行われるたびに、図４２に示したように、このレジスタアドレス以下のペイロードが送信される。
　ステップＳ３５４において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したか否かを判定する。ステップＳ３５４において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したと判定された場合、処理はステップＳ３５５に進む。
　ステップＳ３５５において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、最終データの転送が完了したか否かを判定する。ステップＳ３５５において、最終データの転送が完了していないと判定された場合、処理はステップＳ３５３に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ３５５において、最終データの転送が完了したと判定された場合、処理はステップＳ３５６に進む。ステップＳ３５６において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ストップコマンドを発行する。これにより、Sequence A_Write（AP時）処理は終了し、図５１のステップＳ３２２に処理が戻る。
　一方、ステップＳ３５２またはＳ３５４において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信しなかったと判定された場合、処理はステップＳ３５７に進む。ステップＳ３５７において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ストップコマンドを発行する。この場合、Sequence A_Write（AP時）処理が終了するとともに、通信処理自体が終了される。
　図５４は、図５２のステップＳ３３１において行われるSequence A_Read_CMD（AP時）処理を説明するフローチャートである。なお、図５４では、アプリケーションプロセッサ６１４が行う処理を例に説明するが、図５２のステップＳ３３５のSequence A_Read_CMD（SerDes(Slave)時）処理も同様に行われる。
　ステップＳ３６１において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、スタートコマンドおよびスレーブアドレス（図４２に示したSlave Address+W8-bit）を発行し、タイマを起動する。
　ステップＳ３６２において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したか否かを判定する。ステップＳ３６２において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したと判定された場合、処理はステップＳ３６３に進む。
　ステップＳ３６３において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、レジスタアドレス（図４２に示したRegister Address [15:8]）を発行する。ここで、ステップＳ３６３の処理が繰り返して行われるたびに、図４２に示したように、このレジスタアドレス以下のペイロードの送信が送信される。
　ステップＳ３６４において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したか否かを判定する。
　ステップＳ３６４において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したと判定された場合、処理はステップＳ３６５に進む。
　ステップＳ３６５において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、最終データの転送が完了したか否かを判定する。
　ステップＳ３６５において、最終データの転送が完了したと判定された場合、処理はステップＳ３６６に進む。
　ステップＳ３６６において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ストップコマンドを発行する。その後、処理は２つに分岐し、分岐Ａに従って処理は図５２のステップＳ３３２に進む。一方、分岐Ｂに従って、ステップＳ３６７におてSequence C（AP時）処理（後述する図５５参照）が行われた後、処理は図５２のステップＳ３３９に進む。
　一方、ステップＳ３６５において、最終データの転送が完了していないと判定された場合、処理はステップＳ３６８に進む。
　ステップＳ３６８において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ステップＳ３６１でスタートしたタイマがタイムアウトしたか否かを判定する。ステップＳ３６８において、タイマがタイムアウトしていないと判定された場合、処理はステップＳ３６３に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ３６８において、タイマがタイムアウトしたと判定された場合、処理はステップＳ３６９に進む。
　ステップＳ３６９において、アプリケーションプロセッサ６１４は、Errorレジスタ（Timeout）に１を設定し、Error関連レジスタに拡張パケットヘッダePHおよび拡張パケットフッタePFのデータを格納する。
　ステップＳ３６９の処理後、または、ステップＳ３６２もしくはＳ３６４において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信しなかったと判定された場合、処理はステップＳ３７０に進む。
　ステップＳ３７０において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ストップコマンドを発行する。この場合、Sequence A_Read_CMD（AP時）処理が終了するとともに、通信処理自体が終了される。
　図５５は、図５４のステップＳ３６７において行われるSequence C（AP時）処理を説明するフローチャートである。なお、図５５では、アプリケーションプロセッサ６１４が行う処理を例に説明するが、スレーブ側のSerDes装置６１２においても同様の処理を行うことができる。
　ステップＳ３８１において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、図５４のステップＳ３６１でスタートしたタイマがタイムアウトしたか否かを判定し、タイムアウトしたと判定されるまで処理が待機される。ステップＳ３８１において、タイムアウトしたと判定されると、処理はステップＳ３８２に進み、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ポーリング動作を行う。
　ステップＳ３８３において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、リードコマンドのStatusレジスタ値が１であるか否かを判定する。
　ステップＳ３８３において、リードコマンドのStatusレジスタ値が１であると判定された場合、処理はステップＳ３８４に進む。ステップＳ３８４において、アプリケーションプロセッサ６１４は、リードアクセスを行った後、処理は図５２のステップＳ３３９に戻る。
　一方、ステップＳ３８３において、リードコマンドのStatusレジスタ値が１でない（１以外である）と判定された場合、処理はステップＳ３８５に進む。ステップＳ３８５において、アプリケーションプロセッサ６１４は、Errorレジスタ（Timeout）に１を設定し、Error関連レジスタに拡張パケットヘッダePHおよび拡張パケットフッタePFのデータを格納する。
　ステップＳ３８６において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ストップコマンドを発行する。この場合、Sequence C（AP時）処理が終了するとともに、通信処理自体が終了される。
　図５６は、図５１のステップＳ３２４およびＳ３３４において行われるSequence B（SerDes(Slave)時）処理を説明するフローチャートである。なお、図５６では、スレーブ側のSerDes装置６１２が行う処理を例に説明するが、図５１のステップＳ３２２のSequenceB（SerDes(Master)時）、図５１のステップＳ３２６のSequence B（Image Sensor時）処理、および、図５２のステップＳ３３２のSequence B（SerDes(Master)時）処理も同様に行われる。
　ステップＳ３９１において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestinationSIDを確認する。
　ステップＳ３９２において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestinationSIDとが不一致であるか否かを判定する。
　ステップＳ３９２において、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDとが不一致であると判定された場合、処理はステップＳ３９３に進む。
　ステップＳ３９３において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のDestination SIDと拡張パケットヘッダePHのDestination SIDを確認する。
　ステップＳ３９４において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestinationSIDとが一致したか否かを判定する。
　ステップＳ３９４において、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDとが一致したと判定された場合、処理はステップＳ３９５に進む。
　ステップＳ３９５において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、拡張パケットヘッダePHの内容から、Message Counterを確認する。
　ステップＳ３９６において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２でのMessage Counterと、拡張パケットヘッダePHの内容から確認したMessage Counterの受信値とが一致したか否かを判定する。
　ステップＳ３９６において、スレーブ側のSerDes装置６１２でのMessage Counterと、拡張パケットヘッダePHの内容から確認したMessage Counterの受信値とが一致したと判定された場合、処理はステップＳ３９７に進む。
　ステップＳ３９７において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２で拡張パケットヘッダePHから計算されたCRC計算結果と、拡張パケットフッタePFの受信値（ePF0）とを確認する。
　ステップＳ３９８において、拡張パケットフッタePFの受信値（ePF0）とCRC計算結果とが一致するか否かを判定し、一致すると判定された場合、図５１のステップＳ３２５に処理は戻る。
　一方、ステップＳ３９２において、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDとが不一致でない（一致している）と判定された場合、処理はステップＳ３９９に進む。
　ステップＳ３９９乃至Ｓ４０２では、ステップＳ３９５乃至Ｓ３９８と同様の処理が行われる。
　ステップＳ４０２において、拡張パケットフッタePFの受信値（ePF0）とCRC計算結果とが一致したと判定された場合、処理はステップＳ４０３に進む。ステップＳ４０３において、スレーブ側のSerDes装置６１２のレジスタ６３７にライトアクセスする。
　ステップＳ３９４において、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDとが一致していないと判定された場合、処理はステップＳ４０４に進む。ステップＳ４０４において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、Errorレジスタ[2]（Routing）に１を設定し、Error関連レジスタに拡張パケットヘッダePHおよび拡張パケットフッタePFのデータを格納する。
　ステップＳ３９８またはＳ４０２において、拡張パケットフッタePFの受信値（ePF0）とCRC計算結果とが一致していないと判定された場合、処理はステップＳ４０５に進む。ステップＳ４０５において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、Errorレジスタ（CRC）に１を設定し、Error関連レジスタに拡張パケットヘッダePHおよび拡張パケットフッタePFのデータを格納する。
　ステップＳ３９６またはＳ４００において、スレーブ側のSerDes装置６１２でのMessage Counterと、拡張パケットヘッダePHの内容から確認したMessage Counterの受信値とが一致していないと判定された場合、処理はステップＳ４０６に進む。ステップＳ４０６において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、Errorレジスタ（MC）に１を設定し、Error関連レジスタに拡張パケットヘッダePHおよび拡張パケットフッタePFのデータを格納する。
　ステップＳ４０３乃至Ｓ４０６の処理後、Sequence B（SerDes(Slave)時）処理が終了するとともに、通信処理自体が終了される。
　なお、CRC計算について、E2E Protectionのみを対象として実施しても構わないこと、各デバイスそれぞれでエラー検出すること、パケット破棄する／しないことについて、これらを組み合わせが想定される。
　図５７は、図５２のステップＳ３３９において行われるSequence A_Read_Data（AP時）処理を説明するフローチャートである。なお、図５７では、アプリケーションプロセッサ６１４が行う処理を例に説明するが、図５２のステップＳ３３６のSequence A_Read_Data（SerDes(Slave)時）処理も同様に行われる。
　ステップＳ４１１において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、スタートコマンドおよびスレーブアドレス（図４８に示したSlave Address+W8-bit）を発行する。
　ステップＳ４１２において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したか否かを判定する。ステップＳ４１２において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したと判定された場合、処理はステップＳ４１３に進む。
　ステップＳ４１３において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、スタートコマンドおよびスレーブアドレス（図４８に示したSlave Address+R8-bit）を発行し、タイマを起動する。
　ステップＳ４１４において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したか否かを判定する。ステップＳ４１４において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したと判定された場合、処理はステップＳ４１５に進む。
　ステップＳ４１５において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、アプリケーションプロセッサ６１４側の対向のI2C/I3Cスレーブ６４４からリードデータを取得する。
　ステップＳ４１６において、アプリケーションプロセッサ６１４のI2C/I3Cマスタ６５１がACK送信を行い、かつ、アプリケーションプロセッサ６１４側の対向のI2C/I3Cスレーブ６４４においてACK受信が行われたか否かが判定される。
　ステップＳ４１６において、アプリケーションプロセッサ６１４のI2C/I3Cマスタ６５１がACK送信を行い、かつ、アプリケーションプロセッサ６１４側の対向のI2C/I3Cスレーブ６４４においてACK受信が行われたと判定された場合、処理はステップＳ４１７に進む。
　ステップＳ４１７において、アプリケーションプロセッサ６１４のI2C/I3Cマスタ６５１が、最終データの転送が完了したのに伴ってNACK送信を行ったか否かが判定される。
　ステップＳ４１７において、NACK送信を行ったと判定された場合、処理はステップＳ４１８に進む。ステップＳ４１８において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ストップコマンドを発行する。これにより、Sequence A_Read_Data（AP時）処理は終了し、図５２のステップＳ３４０に処理が戻る。
　一方、ステップＳ４１７において、NACK送信を行っていないと判定された場合、処理はステップＳ４１９に進む。
　ステップＳ４１９において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ステップＳ４１３でスタートしたタイマがタイムアウトしたか否かを判定する。ステップＳ４１９において、タイマがタイムアウトしていないと判定された場合、処理はステップＳ４１５に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ４１９において、タイマがタイムアウトしたと判定された場合、処理はステップＳ４２０に進む。
　ステップＳ４２０において、アプリケーションプロセッサ６１４は、Errorレジスタ（Timeout）に１を設定し、Error関連レジスタに拡張パケットヘッダePHおよび拡張パケットフッタePFのデータを格納する。
　ステップＳ４２０の処理後、または、ステップＳ４１４において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信していないと判定された場合、処理はステップＳ４２１に進む。同様に、ステップＳ４１６において、アプリケーションプロセッサ６１４のI2C/I3Cマスタ６５１がACK送信を行っていない、または、アプリケーションプロセッサ６１４側の対向のI2C/I3Cスレーブ６４４においてACK受信が行われていないと判定された場合、処理はステップＳ４２１に進む。
　ステップＳ４２１において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、ストップコマンドを発行する。この場合、Sequence A_Read_Data（AP時）処理が終了するとともに、通信処理自体が終了される。
　ここで、I2C/I3Cスレーブ６２１が出力（図４６参照）する際に、I2C/I3Cマスタ６３４からI2C/I3Cスレーブ６２１へのアクセスタイミング、および、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４が出力（図４８参照）する際に、I2C/I3Cマスタ６５１からI2C/I3Cスレーブ６４４へのアクセスタイミングには、次に説明する３つの組み合わせがある。
　第１のアクセスタイミングは、リードデータが取得されるまでポーリングして、リードデータの読み出し準備完了後に、I2C/I3Cマスタがリード処理を開始する。
　第２のアクセスタイミングは、一定時間経過後、I2C/I3Cマスタがリード処理を開始する。
　第３のアクセスタイミングは、Clock Stretch方式（後述する図７２参照）を用いて、一定時間経過後、I2C/I3Cマスタがリード処理を開始し、その際、リードデータを塊で送る形態と、リードデータをばらばらに送る形態（Clock Stretch Mode信号をアサート）とがある。
　＜拡張パケットヘッダePHの構成例＞
　図５８乃至図６０は、拡張パケットヘッダePHの構成例を示す図である。
　図５８には、拡張パケットヘッダePH0、拡張パケットヘッダePH1、および拡張パケットヘッダePH2の詳細な構成例が示されている。図示するような拡張パケットヘッダePHの追加は、CCI-FS用に拡張パケットヘッダePHの内容が、C-PHYおよびD-PHYでのePH構造を流用して規定されている。
　図５９には、拡張パケットヘッダePH3の詳細な構成例が示されている。図示するような拡張パケットヘッダePHの追加は、CCI-FS用に拡張パケットヘッダePHの内容が規定されている。
　図６０には、拡張パケットヘッダePHの拡張DTの詳細な構成例が示されている。例えば、CCI-FSに対応するために、拡張パケットヘッダePHのデータタイプに、「0xC0:For I2C」と「0xC1:For I3C」が追加されている。
　＜I2Cの回路構成例＞
　図６１には、従来のI2Cのハードウェアでの構成例が示されている。例えば、ハードウェア実装時で、上位にバス接続構成の場合におけるI2Cの構成例が示されており、スレーブ側は、上位からAKC/NACKを受信できる構成であってもよい。もちろん、一例が示されているものであり、必ずしも上位バス構成が一致するものではない。
　図６２には、I2Cバス上のデータ転送時の波形が示されている。なお、I2Cバス規格とCCI（I2C）は等価なものとする。
　＜通信システム７０１におけるCCI関連の構成例＞
　図６３は、上述の図２７に示した通信システム５０１と同様ように、A-PHY直結構成の通信システム７０１におけるCCI関連の構成例を示すブロック図である。
　図６３に示すように、通信システム７０１は、イメージセンサ７１１およびアプリケーションプロセッサ７１２がA-PHYにより直接的に接続されている。
　イメージセンサ７１１は、A-PHY処理部７２１、CSIA処理部７２２、CSI2処理部５２３、CSI2-FS処理部７２４、CCI処理部７２５、CCI-FS処理部７２６、レジスタ７２７、並びに、セレクタ７２８－１および７２８－２を備えて構成される。図示するように、セレクタ７２８－１および７２８－２は、CCI-FS処理部７２６を挟み込むように配置されており、レジスタ７２７のCCI_FS_Enable信号に従って、CCI-FS処理部７２６の有効／無効を切り替えることができる。
　アプリケーションプロセッサ７１２は、A-PHY処理部７３１、CSIA処理部７３２、CSI2処理部７３３、CSI2-FS処理部７３４、CCI処理部７３５、CCI-FS処理部７３６、レジスタ７３７、並びに、セレクタ７３８－１および７３８－２を備えて構成される。図示するように、セレクタ７３８－１および７３８－２は、CCI-FS処理部７３６を挟み込むように配置されており、レジスタ７３７のCCI_FS_Enable信号に従って、CCI-FS処理部７３６の有効／無効を切り替えることができる。
　例えば、CCI_FS_Enable信号がCCI-FSを有効にすることを示している場合（CCI_FS_Enable=1）、一点鎖線の矢印に示すように、CCI-FS処理部７２６およびCCI-FS処理部７３６を介してデータが送受信される。一方、CCI_FS_Enable信号がCCI-FSを無効にすることを示している場合（CCI_FS_Enable=0）、二点鎖線の矢印に示すように、CCI-FS処理部７２６およびCCI-FS処理部７３６を介さずにデータが送受信される。
　＜ネットワークの接続形態＞
　図６４には、A-PHY直結構成およびSerDes接続構成のネットワークの接続形態（トポロジー）の一例が示されている。
　アプリケーションプロセッサ８０１は、A-PHYを介して直接的にイメージセンサ８０２に接続されており、イメージセンサ８０２は、I2C/I3Cを介してセンサ８０３に接続される接続形態を構成することができる。
　アプリケーションプロセッサ８０１は、I2C/I3Cを介してマスタ側のSerDes装置８０４に接続され、マスタ側のSerDes装置８０４およびスレーブ側のSerDes装置８０５がA-PHYを介して接続されている。スレーブ側のSerDes装置８０５は、I2C/I3Cを介して２つのセンサ８０６－１および８０６－２に接続される接続形態を構成することができる。
　＜CCI-FS処理部の回路構成＞
　図６５は、CCI-FS処理部の回路構成の一例を示すブロック図である。図６５に示すCCIFS処理部９０１およびレジスタ９０２は、上述した各デバイスが備えるCCI-FS処理部およびレジスタで共通の構成となる。
　図６５に示すように、CCI-FS処理部９０１は、上位レイヤにCCI-FSスイッチやレジスタなどが設けられており、下位レイヤにCCI処理部が設けられている。CCI-FS処理部９０１は、CCI-FS送信部９１１およびCCI-FS受信部９１２を備えて構成される。レジスタ９０２からCCI-FS処理部９０１には、各種のレジスタ設定値情報が供給され、CCI-FS処理部９０１からレジスタ９０２には、Error通知が供給される。
　CCI-FS送信部９１１は、拡張パケットヘッダePH生成部９２１、拡張パケットフッタePF生成部９２２、およびDestination Address確認部９２３を備えている。
　拡張パケットヘッダePH生成部９２１は、Message Counterを生成するMC生成部９４１、および、パケット長を計算するPacket Length計算部９４２を有している。拡張パケットフッタePF生成部９２２は、拡張パケットフッタePF1を生成する拡張パケットフッタePF1生成部９４３、および、拡張パケットフッタePF0に格納されるCRCを計算するCRC計算部９４４を有している。
　CCI-FS受信部９１２は、拡張パケットヘッダePH確認部９３１、拡張パケットフッタePF確認部９３２、およびDestination Address確認部９３３を備えている。
　拡張パケットヘッダePH確認部９３１は、Message Counterを確認するMC確認部９５１、および、パケット長を計算および確認するPacket Length計算・確認部９５２を有している。拡張パケットフッタePF確認部９３２は、拡張パケットフッタePF1を確認する拡張パケットフッタePF1確認部９５３、および、拡張パケットフッタePF0に格納されるCRCを計算するCRC計算部９５４を有している。
　CCI-FS処理部９０１は、CCI-FS送信部９１１により、上位レイヤからのデータのDestination Addressを確認して、拡張パケットヘッダePHおよび拡張パケットフッタePFを生成してデータに付加し、下位のレイヤに供給することができる。CCI-FS処理部９０１は、CCI-FS受信部９１２により、下位レイヤからのデータのDestination Addressを確認して、拡張パケットヘッダePHおよび拡張パケットフッタePFを確認し、上位のレイヤに供給することができる。
　ここで、上述した図４０に示したSerDes接続構成の構成例の通信システム６０１を構成する各デバイスのCCI-FS処理部の動作について説明する。
　アプリケーションプロセッサ６１４は、アプリケーションプロセッサ６１４での拡張パケットヘッダePHにおいて、自デバイスを示すSource IDを有する。そして、CCI-FS処理部６５３は、上記情報と、目的とするアクセスを行うデバイスを示すDestination IDを有する情報とを付加する。
　スレーブ側のSerDes装置６１２およびマスタ側のSerDes装置６１３は、自デバイスを示すSource IDを、事前設定されることにより、もしくは固有値として有する。CCI-FS処理部６３６およびCCI-FS処理部６４６は、上記情報と、接続デバイスと目的とするデバイスを示すDestination IDを有する情報との事前設定を行う。
　また、CCI-FS処理部６３６およびCCI-FS処理部６４６は、受信した拡張パケットヘッダePHのDesination IDと自分のID(Source ID)を比較し、自分へのアクセスか、目的とするデバイスを示す(Desination ID)かの判別を行う。例えば、受信した拡張パケットヘッダePHのDesination IDと自分のID(Source ID)とが一致したときは、中間デバイス（SerDes装置）へのアクセスとして、自身のレジスタアクセスを行う。一方、受信した拡張パケットヘッダePHのDesination IDと自分のID(Source ID)とが一致しないときは、後段デバイスへのアクセスとして、接続されたデバイス(Desination ID)へ向けてデータ転送を行う。
　上記のように、拡張パケットヘッダePHに埋め込まれたSource IDとDestination ID、中間デバイス（SerDes装置）または目的とするデバイスに、事前設定または固有値のSourceID、事前設定された接続先情報を元にデータを転送し、目的とするデバイスへ向けてアクセスを行う。
　イメージセンサ６１１のCSI2-FS処理部６２３は、受信した拡張パケットヘッダePHのDestination IDと、自分のID（Source ID）とが一致したときは、イメージセンサ６１１へのアクセスとして、自身のレジスタアクセスを行う。
　このように、各デバイスが有するSource IDは、それぞれのデバイスに対して固有の値、事前設定された値、もしくはそれらの組み合わせを用いることができる。
　図６６乃至図６８は、レジスタ９０２の詳細な構成例を示す図である。
　図６６には、レジスタ９０２のアドレス0x000からアドレス0x109までの詳細が示されている。図６７には、レジスタ９０２のアドレス0x110からアドレス0x125までの詳細として、Bridge構成時の構成例が示されている。
　図６８には、レジスタ９０２のアドレス0x200の詳細として、Error関連レジスタが示されている。図６８には、レジスタ９０２のアドレス0x300およびアドレス0x400の詳細として、Error関連レジスタ（debug）が示されている。図６８には、レジスタ９０２のアドレス0x800の詳細として、Error Injection関連レジスタ（debug）が示されている。
　＜拡張パケットヘッダePHの変形例＞
　図６９および図７０を参照して、拡張パケットヘッダePHの変形例について説明する。
　図６９には、上述の図３３を参照して説明したように、ライトアクセス時に、アプリケーションプロセッサ５１２のCCI-FS処理部５３６で生成されるライトデータのパケット構成における拡張パケットヘッダePHの変形例が示されている。図６９に示す拡張パケットヘッダePHは、拡張パケットヘッダePH3および拡張パケットヘッダePH4の構成が、上述の図３３に示した構成例と異なっている。
　図７０には、上述の図２８を参照して説明したように、リードアクセス時に、アプリケーションプロセッサ５１２のCCI-FS処理部５３６において生成されるライトデータのパケット構成における拡張パケットヘッダePHの変形例が示されている。図７０に示す拡張パケットヘッダePHは、拡張パケットヘッダePH3および拡張パケットヘッダePH4の構成が、上述の図２８に示した構成例と異なっている。
　例えば、図６９および図７０に示す拡張パケットヘッダePHでは、実装依存で、以下のような組み合わせが想定される。
　Readアドレス情報を拡張パケットヘッダePHに格納しても、AP(CCI)ペイロードに格納してもよい。Length情報を拡張パケットヘッダePHに格納しても、AP(CCI)ペイロードに格納してもよい。CMDの情報を、拡張パケットヘッダePHのCCI Command IDに格納してもよい。CCI Command IDに基づいて、コマンドの開始、再開、および終了情報が参照される。CCIHeader Lengthを用いて、AP(CCI)ペイロードにCCIの情報（例えば、Slave Addressなど）を格納してもよい。CCI Header Lengthは、CCIプロトコル(I2C)のヘッダ長を示す情報である。
　図７１は、図２７に示したようなA-PHY直結構成におけるイメージセンサ５１１およびアプリケーションプロセッサ５１２との間のフローを説明する図である。
　アプリケーションプロセッサ５１２では、CCI-FSスイッチ５３８が、リードコマンドおよびライトコマンドを発行する。CCI-FSスイッチ５３８は、スレーブアドレス（Slave Address+W 8bit）、レジスタアドレス（Register Address[15:8]、Register Address[7:0]）、および、データ（Data*(*=N)[7:0]）を、CCI処理部５３５に供給する。CCI処理部５３５は、それらをAP(CCI)ペイロードに変換して、A-PHY処理部５３１に供給する。A-PHY処理部５３１は、AP(CCI)ペイロードにA-PHYヘッダおよびA-PHYフッタを付加し、イメージセンサ５１１へA-PHY転送を行う。
　イメージセンサ５１１では、A-PHY処理部５２１が、A-PHYヘッダおよびA-PHYフッタを除去してAP(CCI)ペイロードをCCI処理部５２５に供給する。CCI処理部５２５は、AP(CCI)ペイロードを変換し、その内容に基づいて、ライトコマンドに従ってレジスタ５２７にデータを書き込み、リードコマンドに従ってレジスタ５２７からデータを読み出す。
　このとき、CCI-FS Enableの初期設定は、CCI処理部５２５により行われ、レジスタインタフェースやAHBバスなどのバス変換が行われる。そして、CCI-FS Enable設定の確認は、CCI処理部５２５またはCCI-FS処理部５２６を経由して行われる。
　CCI処理部５２５は、リードコマンドに応じてレジスタ５２７から読み出されたリードデータ（Data*(*=M)[7:0]）をAP(CCI)ペイロードに変換して、A-PHY処理部５２１に供給する。A-PHY処理部５２１は、AP(CCI)ペイロードにA-PHYヘッダおよびA-PHYフッタを付加し、アプリケーションプロセッサ５１２へA-PHY転送を行う。
　アプリケーションプロセッサ５１２では、A-PHY処理部５３１が、A-PHYヘッダおよびAPHYフッタを除去してAP(CCI)ペイロードをCCI処理部５３５に供給する。CCI処理部５３５は、AP(CCI)ペイロードを変換し、リードデータ（Data*(*=M)[7:0]）をCCI-FSスイッチ５３８に供給する。
　CCI-FSスイッチ５３８は、レジスタ５３７に対してCCI-FS Enable設定およびCCI-FS関連各種レジスタ設定を行う。このとき、レジスタアクセスは、実装に依存する。CCI-FSスイッチ５３８は、レジスタ５３７、CCI-FS処理部５３６、A-PHY処理部５３１、A-PHY処理部５２１、CCI-FS処理部５２６を介して、レジスタ５２７に対してCCI-FS関連各種レジスタ設定を行う。
　アプリケーションプロセッサ５１２では、CCI-FSスイッチ５３８が、リードコマンドを発行する。CCI-FSスイッチ５３８は、スレーブアドレス（Slave Address+W 8bit）、レジスタアドレス（Register Address[15:8]、Register Address[7:0]）、および、データ（Data*(*=N)[7:0]）を、レジスタ５３７に供給する。CCI-FS処理部５３６は、それらをAP(CCI)ペイロードに変換し、拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0を付加して、A-PHY処理部５３１に供給する。A-PHY処理部５３１は、それらにA-PHYヘッダおよびA-PHYフッタを付加し、イメージセンサ５１１へA-PHY転送を行う。
　イメージセンサ５１１では、A-PHY処理部５２１が、A-PHYヘッダおよびA-PHYフッタを除去して、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0を、CCI-FS処理部５２６に供給する。CCI-FS処理部５２６は、AP(CCI)ペイロードを変換し、その内容に基づいて、リードコマンドに従ってレジスタ５２７からデータを読み出す。このとき、レジスタアクセスは、実装に依存し、レジスタインタフェースやAHBバス、CCIインタフェースなどのバス変換が行われる。
　CCI-FS処理部５２６は、リードコマンドに応じてレジスタ５２７から読み出されたリードデータ（Data*(*=M)[7:0]）をAP(CCI)ペイロードに変換し、拡張パケットヘッダePH*(*=n)、拡張パケットフッタePF1、および拡張パケットフッタePF0を付加して、A-PHY処理部５２１に供給する。A-PHY処理部５２１は、それらにA-PHYヘッダおよびA-PHYフッタを付加し、アプリケーションプロセッサ５１２へA-PHY転送を行う。
　アプリケーションプロセッサ５１２では、A-PHY処理部５３１が、A-PHYヘッダおよびAPHYフッタを除去して、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0を、CCI-FS処理部５３６に供給する。CCIFS処理部５３６は、AP(CCI)ペイロードを変換し、リードデータ（Data*(*=M)[7:0]）をCCI-FSスイッチ５３８に供給する。
　なお、上述したフローは、ハードウェアでのI2C/I3Cコマンド生成を例に説明を行ったが、その他、以下のような組み合わせがある。
　ソフトウェアの場合、ソフトウェアでのI2C/I3C生成として、Slave Address、Registerアドレス、Payload、ACK応答受信、送信、各種制御コード（Ｓ，Ｓｒ，ACK，NACK，Ｐ）がソフトウェアで生成（例えば、GPIO制御のイメージ）される。ソフトウェアでのI2C/I3Cコマンド生成として、CPUバス設定でACK受信に応じて、CPUから、Slave Address、Registerアドレス、Payloadを発行する。
　ハードウェアの場合、ハードウェアでのI2C/I3C生成として、I2C/I3CのHW IPに転送設定、データを設定する。各種制御コードはハードウェアで自動応答する。ハードウェアでのI2C/I3Cコマンド生成として、I2C/I3CのHW IPに転送設定でデータを設定し、コマンドで送信を行う。各種制御コードはハードウェアで自動応答する。
　図７２は、図４０に示したようなSerDes接続構成におけるイメージセンサ６１１およびアプリケーションプロセッサ６１４の間のWriteアクセスおよびReadアクセスにおいて、Clock Stretch方式を用いたフローを説明する図である。
　アプリケーションプロセッサ６１４のCCI-FSスイッチ６５５は、スタートコマンドおよびライトコマンド（Slave Address+W 8bit）を、マスタ側のSerDes装置６１３のCCI処理部６４５に供給し、Scl_enb信号をアサートする。マスタ側のSerDes装置６１３では、CCI処理部６４５が、ライトコマンドをA-PHY処理部６４１に供給し、A-PHY処理部６４１は、ライトコマンドにA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを除去してライトコマンドを、CCI処理部６３５（Slave）に供給する。CCI処理部６３５（Slave）は、Scl_enb信号をネゲートするとともにライトコマンドをCCI処理部６３５（Master）に供給する。ここで、マスタ側のSerDes装置６１３側との通信を行ってスレーブとして機能するCCI処理部６３５をCCI処理部６３５（Slave）と称し、イメージセンサ６１１側と通信を行ってマスタとして機能するCCI処理部６３５をCCI処理部６３５（Master）と称する。
　CCI処理部６３５（Master）は、スタートコマンドおよびライトコマンドを、イメージセンサ６１１に送信する。
　イメージセンサ６１１では、CCI処理部６２２が、スタートコマンドおよびライトコマンドを受信してCSI2-FS処理部６２３に供給する。CSI2-FS処理部６２３は、その受信に成功したことを示すACK応答をCCI処理部６２２に供給し、CCI処理部６２２は、スレーブ側のSerDes装置６１２にACK応答を送信する。
　スレーブ側のSerDes装置６１２では、CCI処理部６３５（Master）がACK応答を受信し、CCI処理部６３５（Slave）からScl_enb信号がネゲートされると、ACK応答をCCI-FS処理部６３６に供給する。その後、CCI処理部６３５（Slave）は、CCI処理部６３５（Master）にScl_enb信号をアサートする。
　CCI-FS処理部６３６は、ACK応答をA-PHY処理部６３１に供給する。A-PHY処理部６３１は、ACK応答にA-PHYヘッダおよびA-PHYフッタを付加し、マスタ側のSerDes装置６１３へA-PHY転送を行う。
　マスタ側のSerDes装置６１３では、A-PHY処理部６４１が、A-PHYヘッダおよびA-PHYフッタを除去してACK応答をCCI処理部６４５に供給する。アプリケーションプロセッサ６１４のCCI-FSスイッチ６５５が、CCI処理部６４５に対してScl_enb信号をネゲートすると、CCI処理部６４５は、アプリケーションプロセッサ６１４にACK応答を送信する。
　アプリケーションプロセッサ６１４では、CCI処理部６５２がACK応答を受信して、CCI-FS処理部６５３を介してCCI-FSスイッチ６５５に供給する。
　アプリケーションプロセッサ６１４のCCI-FSスイッチ６５５は、レジスタアドレス（Register Address[7:0]）を、マスタ側のSerDes装置６１３のCCI処理部６４５に供給し、Scl_enb信号をアサートする。マスタ側のSerDes装置６１３では、CCI処理部６４５が、レジスタアドレスをA-PHY処理部６４１に供給し、A-PHY処理部６４１は、レジスタアドレスにA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを除去してレジスタアドレスを、CCI処理部６３５（Slave）に供給する。CCI処理部６３５（Slave）は、Scl_enb信号をネゲートするとともにレジスタアドレスをCCI処理部６３５（Master）に供給する。CCI処理部６３５（Master）は、レジスタアドレスを、イメージセンサ６１１に送信する。その後、CCI処理部６３５（Slave）は、CCI処理部６３５（Master）にScl_enb信号をアサートする。
　イメージセンサ６１１では、CCI処理部６２２が、レジスタアドレスを受信してCSI2-FS処理部６２３に供給する。CSI2-FS処理部６２３は、その受信に成功したことを示すACK応答をCCI処理部６２２に供給し、CCI処理部６２２は、スレーブ側のSerDes装置６１２にACK応答を送信する。
　その後、上述した処理と同様に、ACK応答がCCI-FSスイッチ６５５まで供給される。
　アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、CCI-FSスイッチ６５５の制御に従って、マスタ側のSerDes装置６１３へ拡張パケットヘッダePH*(*=n)を送信する。
　マスタ側のSerDes装置６１３では、CCI処理部６４５が、拡張パケットヘッダePH*(*=n)を受信し、CCI-FSスイッチ６５５からScl_enb信号がアサートされると、拡張パケットヘッダePH*(*=n)をA-PHY処理部６４１に供給する。その後、CCI-FSスイッチ６５５は、CCI処理部６４５にScl_enb信号をネゲートする。A-PHY処理部６４１は、拡張パケットヘッダePH*(*=n)にA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを除去して拡張パケットヘッダePH*(*=n)を、CCI-FS処理部６３６に供給する。CCI-FS処理部６３６は、Scl_enb信号をネゲートするとともに拡張パケットヘッダePH*(*=n)をCCI処理部６３５（Master）に供給する。CCI処理部６３５（Master）は、拡張パケットヘッダePH*(*=n)を、イメージセンサ６１１に送信する。その後、CCI処理部６３５（Slave）は、CCI処理部６３５（Master）にScl_enb信号をアサートする。
　イメージセンサ６１１では、CSI2-FS処理部６２３が、拡張パケットヘッダePH*(*=n)を受信する。CSI2-FS処理部６２３は、その受信に成功したことを示すACK応答をCCI処理部６２２に供給し、CCI処理部６２２は、スレーブ側のSerDes装置６１２にACK応答を送信する。
　その後、上述した処理と同様に、ACK応答がCCI-FSスイッチ６５５まで供給される。
　アプリケーションプロセッサ６１４のCCI-FSスイッチ６５５は、ライトデータ（Dara0[7:0]）を、マスタ側のSerDes装置６１３のCCI処理部６４５に供給し、Scl_enb信号をアサートする。マスタ側のSerDes装置６１３では、CCI処理部６４５が、ライトデータをA-PHY処理部６４１に供給し、A-PHY処理部６４１は、ライトデータにA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　マスタ側のSerDes装置６１３では、CCI処理部６４５が、ライトデータを受信し、CCI-FSスイッチ６５５からScl_enb信号がアサートされると、ライトデータをA-PHY処理部６４１に供給する。その後、CSI2-FS処理部６５３は、CCI-FSスイッチ６５５の制御に従って、CCI処理部６４５にScl_enb信号をネゲートする。A-PHY処理部６４１は、ライトデータにA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを除去してライトデータを、CCI処理部６３５に供給する。CCI処理部６３５は、Scl_enb信号をネゲートするとともにライトデータをCCI処理部６３５（Master）に供給する。CCI処理部６３５（Master）は、ライトデータをイメージセンサ６１１に送信する。その後、CCI処理部６３５（Slave）は、CCI処理部６３５（Master）にScl_enb信号をアサートする。
　イメージセンサ６１１では、CCI処理部６２２がライトデータを受信してCSI2-FS処理部６２３に供給し、CSI2-FS処理部６２３がレジスタ６２４にライトデータを書き込む。CSI2-FS処理部６２３は、ライトデータの書き込みに成功したことを示すACK応答をCCI処理部６２２に供給し、CCI処理部６２２は、スレーブ側のSerDes装置６１２にACK応答を送信する。
　その後、上述した処理と同様に、ACK応答がCCI-FSスイッチ６５５まで供給される。
　アプリケーションプロセッサ６１４では、CCI-FS処理部６５３が、CCI-FSスイッチ６５５の制御に従って、マスタ側のSerDes装置６１３へ拡張パケットフッタePF0を送信する。
　マスタ側のSerDes装置６１３では、CCI処理部６４５が、拡張パケットフッタePF0を受信し、CCI-FSスイッチ６５５からScl_enb信号がアサートされると、拡張パケットフッタePF0をA-PHY処理部６４１に供給する。その後、CCI-FSスイッチ６５５は、CCI処理部６４５にScl_enb信号をネゲートする。A-PHY処理部６４１は、拡張パケットフッタePF0にA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを除去して拡張パケットフッタePF0を、CCI-FS処理部６３６に供給する。CCI-FS処理部６３６は、Scl_enb信号をネゲートするとともに拡張パケットフッタePF0をCCI処理部６３５（Master）に供給する。CCI処理部６３５（Master）は、拡張パケットフッタePF0を、イメージセンサ６１１に送信する。その後、CCI処理部６３５（Slave）は、CCI処理部６３５（Master）にScl_enb信号をアサートする。
　イメージセンサ６１１では、CSI2-FS処理部６２３が、拡張パケットフッタePF0を受信する。CSI2-FS処理部６２３は、その受信に成功したことを示すACK応答をCCI処理部６２２に供給し、CCI処理部６２２は、スレーブ側のSerDes装置６１２にACK応答を送信する。
　その後、上述した処理と同様に、ACK応答がCCI-FSスイッチ６５５まで供給される。
　アプリケーションプロセッサ６１４のCCI-FSスイッチ６５５は、リピートスタートコマンドおよびリードコマンド（Slave Address+R 8bit）を、マスタ側のSerDes装置６１３のCCI処理部６４５に供給し、Scl_enb信号をアサートする。マスタ側のSerDes装置６１３では、CCI処理部６４５が、リードコマンドをA-PHY処理部６４１に供給し、A-PHY処理部６４１は、リードコマンドにA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを除去してリードコマンドを、CCI処理部６３５（Slave）に供給する。CCI処理部６３５（Slave）は、Scl_enb信号をネゲートするとともにリードコマンドをCCI処理部６３５（Master）に供給する。CCI処理部６３５（Master）は、リピートスタートコマンドおよびリードコマンドを、イメージセンサ６１１に送信する。
　イメージセンサ６１１では、CCI処理部６２２が、リピートスタートコマンドおよびリードコマンドを受信して、レジスタ６２４に対してアクセスする。CCI処理部６２２は、その受信に成功したことを示すACK応答を、スレーブ側のSerDes装置６１２に送信する。
　その後、上述した処理と同様に、ACK応答がCCI-FSスイッチ６５５まで供給される。
　イメージセンサ６１１では、CCI処理部６２２が、レジスタ６２４からリードデータ（Data0[7:0]）を読み出して、スレーブ側のSerDes装置６１２に送信する。
　スレーブ側のSerDes装置６１２では、CCI処理部６３５（Master）が、リードデータを受信してCCI処理部６３５（Slave）に供給し、CCI処理部６３５（Slave）は、リードデータをA-PHY処理部６３１に供給する。A-PHY処理部６３１は、リードデータにA-PHYヘッダおよびA-PHYフッタを付加し、マスタ側のSerDes装置６１３へA-PHY転送を行う。
　マスタ側のSerDes装置６１３では、A-PHY処理部６４１が、A-PHYヘッダおよびA-PHYフッタを除去してリードデータをCCI処理部６４５に供給し、CCI処理部６４５は、アプリケーションプロセッサ６１４にリードデータを送信する。
　アプリケーションプロセッサ６１４では、CCI処理部６５２がリードデータを受信して、CCI-FS処理部６５３を介してCCI-FSスイッチ６５５に供給する。
　CCI-FSスイッチ６５５は、NACK応答およびストップコマンドをCCI処理部６４５に送信する。CCI処理部６４５は、NACK応答およびストップコマンドをA-PHY処理部６４１に供給する。A-PHY処理部６４１は、NACK応答およびストップコマンドにA-PHYヘッダおよびA-PHYフッタを付加し、スレーブ側のSerDes装置６１２へA-PHY転送を行う。
　スレーブ側のSerDes装置６１２では、A-PHY処理部６３１が、A-PHYヘッダおよびA-PHYフッタを除去してNACK応答およびストップコマンドを、CCI処理部６３５（Slave）に供給する。CCI処理部６３５（Slave）は、NACK応答およびストップコマンドをCCI処理部６３５（Master）に供給し、CCI処理部６３５（Master）は、NACK応答およびストップコマンドを、イメージセンサ６１１に送信する。
　イメージセンサ６１１では、CCI処理部６２２が、NACK応答およびストップコマンドを受信してCSI2-FS処理部６２３に供給する。
　なお、図７２で説明したフローにおいて、スタート、リピートスタート、ACK応答、NACK応答、ストップなどのI2Cの制御コマンドは、拡張パケットヘッダePH0のControl Code Indicatorを１に設定し、1ByteのPayloadに割り当てられた各コードを示す。
　＜イメージセンサおよびアプリケーションプロセッサの詳細な構成例＞
　（イメージセンサの詳細な構成例）
　図７３は、上述した図２５に示したイメージセンサ２１１がCCI-FS処理部１００１を備える構成の構成例を示すブロック図である。なお、図７３に示すイメージセンサ２１１では、図２５のイメージセンサ２１１と共通する構成には同一の符号を付し、その説明は省略する。
　図７３に示すように、CCI-FS処理部１００１は、CCIスレーブ２２４およびレジスタ４７の間に配置され、CCI-FS処理部１００１を挟み込むようにMUX部１００２－１および１００２－２が配置されている。MUX部１００２－１および１００２－２は、レジスタ４７から供給されるcci_fs_en信号に従って、CCI-FS処理部１００１を有効にする場合には、CCI-FS処理部１００１を介してデータを送受信する。一方、MUX部１００２－１および１００２－２は、レジスタ４７から供給されるcci_fs_en信号に従って、CCI-FS処理部１００１を無効にする場合には、CCI-FS処理部１００１を介さずにデータを送受信する。
　（アプリケーションプロセッサの詳細な構成例）
　図７４は、上述した図２６に示したアプリケーションプロセッサ２１４がCCI-FS処理部１１０１を備える構成の構成例を示すブロック図である。なお、図７４に示すアプリケーションプロセッサ２１４では、図２６のアプリケーションプロセッサ２１４と共通する構成には同一の符号を付し、その説明は省略する。
　図７４に示すように、CCI-FS処理部１１０１はCCIマスタ２５４およびレジスタ７３の間に配置され、CCI-FS処理部１１０１を挟み込むようにMUX部１１０２－１および１１０２－２が配置されている。MUX部１１０２－１および１１０２－２は、レジスタ７３から供給されるcci_fs_en信号に従って、CCI-FS処理部１１０１を有効にする場合には、CCI-FS処理部１１０１を介してデータを送受信する。一方、MUX部１１０２－１および１１０２－２は、レジスタ７３から供給されるcci_fs_en信号に従って、CCI-FS処理部１１０１を無効にする場合には、CCI-FS処理部１１０１を介さずにデータを送受信する。
　なお、拡張パケットヘッダePHの構成における各fieldの実装方法に関しては、以下のような構成を採用してもよい。・拡張VCは、Safe CCIでは未使用とする。（MIPIでの拡張ヘッダ関連とHeader fieldを合わせるために同様の構成としている）・拡張DTでは、上位からのバスのコマンド関連の情報に埋め込んでもよいし、レジスタ設定からの信号線の設定の実装構成としてもよい。・Protocolは、I2Cで記載しているが、I3CのSDRモードでも同様のことが実施することができる。
　＜通信システムの構成例＞
　図７５乃至図１１７を参照して、本技術を適用した通信システムの第４の実施の形態について説明する。
　図７５は、第４の実施の形態の通信システムのブロック図である。図７５のＡには、第１のバリエーションとなる通信システム１２０１が示されており、図７５のＢには、第２のバリエーションとなる通信システム１２０１Ａが示されている。
　図７５のＡに示されている通信システム１２０１は、イメージセンサ１２１１およびアプリケーションプロセッサ１２１２が直接的に接続されて構成される。
　イメージセンサ１２１１は、A-PHY層１２２１の上にALL層１２２２が配置され、その上に、CSI-2送信部１２２３およびCSI拡張部１２２４、並びに、CCIスレーブ１２２５およびCCI拡張部１２２６が配置された構成となっている。イメージセンサ１２１１は、CSI-2送信部１２２３に対してCSI拡張部１２２４を設けること、および、CCIスレーブ１２２５に対してCCI拡張部１２２６を設けることによって、それぞれ拡張された規格に対応することが可能となる。
　アプリケーションプロセッサ１２１２は、A-PHY層１２３１の上にALL層１２３２が配置され、その上に、CSI-2受信部１２３３およびCSI拡張部１２３４、並びに、CCIマスタ１２３５およびCCI拡張部１２３６が配置された構成となっている。アプリケーションプロセッサ１２１２は、CSI-2受信部１２３３に対してCSI拡張部１２３４を設けること、および、CCIマスタ１２３５に対してCCI拡張部１２３６を設けることによって、それぞれ拡張された規格に対応することが可能となる。なお、CSI拡張は、Camera Service Extensions（CSE）と称されてもよい。
　図７５のＢに示されている通信システム１２０１Ａは、ディスプレイ１２１３およびアプリケーションプロセッサ１２１２Ａが接続されて構成される。なお、アプリケーションプロセッサ１２１２Ａは、図７５のＡのアプリケーションプロセッサ１２１２のCSI-2受信部１２３３およびCSI拡張部１２３４に替えて、DSI-2送信部１２３３ＡおよびDSI拡張部１２３４Ａを備えて構成されており、その他のブロックはアプリケーションプロセッサ１２１２と共通の構成となっている。
　ディスプレイ１２１３は、A-PHY層１２４１の上にALL層１２４２が配置され、その上に、DSI-2受信部１２４３およびDSI拡張部１２４４、並びに、CCIスレーブ１２４５およびCCI拡張部１２４６が配置された構成となっている。ディスプレイ１２１３は、DSI-2受信部１２４３に対してDSI拡張部１２４４を設けること、および、CCIスレーブ１２４５に対してCCI拡張部１２４６を設けることによって、それぞれ拡張された規格に対応することが可能となる。なお、DSI拡張は、Display Service Extensions（DSE）と称されてもよい。
　このように構成される通信システム１２０１および１２０１Ａは、画像データを含むフレームのデータを片方向へ送信する高速データ送信と、高速データ送信に関連するコマンドを逆方向へ送信する低速コマンド送信（ただし、コマンドそのものを送信することをコマンド送信と称してもよいし、コマンドに対する応答を送信することをコマンド送信と称してもよい）とを少なくとも行うことができる。例えば、低速コマンド送信では、高速データ送信の開始を要求する高速データ送信開始命令の送信が少なくとも行われるが、その限りではなくてもよい。また、高速データ送信は、低速コマンド送信と比較して高速であり、高速データ送信開始命令の受信に応じて開始されるが、その限りではなくてもよい。
　ただし、アプリケーションプロセッサ１２１２の通信相手がイメージセンサ１２１１である通信システム１２０１と、アプリケーションプロセッサ１２１２Ａの通信相手がディスプレイ１２１３である通信システム１２０１Ａとでは、高速データ送信および低速コマンド送信の方向が異なる。つまり、通信システム１２０１では、イメージセンサ１２１１からアプリケーションプロセッサ１２１２へ画像データが送信され、通信システム１２０１Ａでは、アプリケーションプロセッサ１２１２Ａからディスプレイ１２１３へ画像データが送信される。
　物理層規格のA-PHYにおいて、高速データ送信と低速コマンド送信とは、共通の通信経路を一部または全部に介して送信される。また、A-PHYは、アプリケーションプロセッサ１２１２からイメージセンサ１２１１に対する電力供給、および、アプリケーションプロセッサ１２１２Ａからディスプレイ１２１３に対する電力供給の一部または全部が、共通な通信経路を介して伝送することを可能とするオプションをサポートする。
　ところで、低速コマンド送信は、例えば、CSI-2の規格のCCIに準拠し、I2CまたはI3Cの規格に基づいて通信が行われる。このとき、低速コマンド送信は、I2CまたはI3Cの独立した物理層だけでなく、D-PHY、C-PHY、およびA-PHYの何れかの物理層の一部または全部を共用してコマンドを伝送することが可能である。一方、高速データ送信は、D-PHY、C-PHY、およびA-PHYの何れかの物理層の一部または全部を介してデータを伝送する。
　なお、低速コマンド送信は、例えばCSI-2の規格内のUnified Serial Link（USL）に準拠する場合、D-PHYまたはC-PHYの何れかの物理層の一部または全部に介してコマンドを伝送することが可能である。つまり、高速データ送信と低速コマンド送信とは、D-PHY、C-PHY、A-PHY、I2C、およびI3Cの何れかの物理層を一部または全部に介した伝送が可能である。
　なお、図７５では、アプリケーションプロセッサ１２１２および１２０１Ａを備えた構成例について説明したが、通信システム１２０１および１２０１Ａは、例えば、電子制御ユニット（ECU：Electronic Control Unit）を備えた構成としてもよい。即ち、イメージセンサ１２１１やディスプレイ１２１３などと直接接続または間接接続で通信を行うことができるプロセッサであれば、アプリケーションプロセッサ１２１２に限定されることはない。また、イメージセンサ１２１１以外の各種のセンサを備える構成としてもよい。
　このように構成される通信システム１２０１および１２０１Ａは、以下で説明するようなナンス値の送信方法またはナンス値を含む初期化ベクトル構成を採用する。
　具体的には、特定の共通鍵暗号アルゴリズム（例えば、AES-GCM/GMAC）ではナンス値を含む初期化ベクトルが必要になる。このため、イメージセンサ１２１１およびアプリケーションプロセッサ１２１２の間で、または、ディスプレイ１２１３およびアプリケーションプロセッサ１２１２Ａの間で、初期化ベクトルおよびナンス値の設定ルールが事前に合意されることになる。
　しかしながら、イメージセンサ１２１１、アプリケーションプロセッサ１２１２および１２０１Ａ、並びにディスプレイ１２１３それぞれの内部で、ナンス値の誤認識または改竄が発生すると、それ以降は暗号化された画像データの復号やメッセージの認証などに失敗してしまう。そのため、画像データの送信が正常に行われなくなってしまう不具合を回避するために、ナンス値の誤認識および改竄に関する対策技術が必要であった。
　一方、MIPI Camera Serial Interface（CSI）規格またはMIPI Display Serial Interface（DSI）規格に対する新たなセキュリティ仕様として、CSI規格またはDSI規格に適した初期化ベクトルを定義する必要があった。そこで、本技術は、イメージセンサ１２１１を含むCSI規格に準拠する撮像装置、または、ディスプレイ１２１３を含むDSI規格に準拠する表示装置に好適な、ナンス値の送信方法またはナンス値を含む初期化ベクトル構成を開示する。
　なお、以下では、イメージセンサ１２１１およびアプリケーションプロセッサ１２１２の間で行われる処理について説明するが、ディスプレイ１２１３およびアプリケーションプロセッサ１２１２Ａの間でも、同様の処理を行うことができる。
　＜図７５のイメージセンサの詳細な構成例＞
　図７６は、イメージセンサ１２１１の詳細な構成例を示すブロック図である。
　イメージセンサ１２１１は、画素１３０１、AD変換器１３０２、画像処理部１３０３、拡張モード対応CSI-2送信回路１３０４、物理層処理部１３０５、I2C/I3Cスレーブ１３０６、記憶部１３０７、メッセージカウンタ１３０８、ナンス更新部１３０９、およびセキュリティ部１３１０を備えて構成される。なお、画素１３０１、AD変換器１３０２、画像処理部１３０３、拡張モード対応CSI-2送信回路１３０４、物理層処理部１３０５、I2C/I3Cスレーブ１３０６、および記憶部１３０７は、上述した他の実施の形態において対応する各ブロックと同様に構成され、その詳細な説明は省略する。
　メッセージカウンタ１３０８は、所定カウント条件を満たす拡張パケットを送信するたびにイメージセンサ１２１１内のメッセージカウント値を更新する。
　セキュリティ部１３１０は、イメージセンサ１２１１内のセッション鍵を導出し、高速データ送信されるデータの第１保護データ（例えば、完全性を保護するために演算された完全性演算値、機密性を保護するために暗号化された暗号データ）を、そのセッション鍵を用いて生成する。
　ナンス更新部１３０９は、セキュリティ部１３１０が第１保護データを生成するたびに、イメージセンサ１２１１内のナンス（nonce；number used once）値を更新する。
　このように構成されるイメージセンサ１２１１は、ナンス値の一部または全部、および、メッセージカウント値の一部または全部を、アプリケーションプロセッサ１２１２へ高速データ送信する。例えば、ナンス値の一部または全部は、カウント値または乱数であってもよい。また、ナンス値の一部または全部は、拡張パケットヘッダ外に格納されて送信され、画像データは、パケットデータ内に格納されて送信される。
　イメージセンサ１２１１では、メッセージカウンタ１３０８およびナンス更新部１３０９が、別体で構成されていても、一体で構成されていてもよい。例えば、メッセージカウンタ１３０８およびナンス更新部１３０９が別体で構成されている場合、ナンス値およびメッセージカウント値の更新が非同期とすることができる。これにより、ナンス値およびメッセージカウント値の自由度を高めることができる。
　一方、メッセージカウンタ１３０８およびナンス更新部１３０９が一体で構成されている場合、ナンス値およびメッセージカウント値の更新を同期することができる。その場合、メッセージカウント値は、ナンス値としてカウント値を用いていれば、ナンス値の一部または全部と共有することで、メッセージカウンタ１３０８のビット幅を節約することができる。つまり、メッセージカウンタ１３０８は、ナンス更新部１３０９の一部または全部としてもよく、ナンス更新部１３０９と一部または全部が共通化することができる。
　＜図７５のプリケーションプロセッサの詳細な構成例＞
　図７７は、アプリケーションプロセッサ１２１２の詳細な構成例を示すブロック図である。
　アプリケーションプロセッサ１２１２は、物理層処理部１３２１、拡張モード対応CSI-2受信回路１３２２、I2C/I3Cマスタ１３２３、記憶部１３２４、データ検証部１３２５、セキュリティ部１３２６、およびコントローラ１３２７を備えて構成される。なお、物理層処理部１３２１、拡張モード対応CSI-2受信回路１３２２、I2C/I3Cマスタ１３２３、および記憶部１３２４は、上述した他の実施の形態において対応する各ブロックと同様に構成され、その詳細な説明は省略する。
　データ検証部１３２５は、イメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信されたナンス値またはメッセージカウント値の妥当性を検証する。
　セキュリティ部１３２６は、イメージセンサ１２１１内のセッション鍵に対応するアプリケーションプロセッサ１２１２内のセッション鍵を導出し、アプリケーションプロセッサ１２１２内のセッション鍵を用いて画像データの第１保護データを検証（完全性の検証）または復号する。
　このように構成されるアプリケーションプロセッサ１２１２は、被検証データがカウント値である場合、データ検証部１３２５は、その連続性を検証することができる。また、データ検証部１３２５がカウンタを備えた構成とし、イメージセンサ１２１１と同様にカウント値を更新することで比較検証を行うようにしてもよい。なお、被検証データが乱数である場合、データ検証部１３２５は、その乱数性を検証してもよい。なお、データ検証部１３２５は、ナンス更新部１３０９（またはメッセージカウンタ）を備え、これを用いて第１保護データを検証または復号してもよく、これを用いて被検証データを検証してもよい。
　イメージセンサ１２１１およびアプリケーションプロセッサ１２１２は、所望の移動体装置に搭載される構成とすることができる。例えば、移動体装置は、持ち運び可能なモバイル装置であってもよく、例えば、携帯電話、スマートフォン、デジタルカメラ、ゲーム機器などの何れかであってもよい。移動体装置は、推進装置であってもよく、例えば、推進（可動、走行、歩行、飛行などの何れか）することが可能な車両、ロボット、ドローンなどの何れかであってもよい。移動体装置は、AI（Artificial Intelligence）機能を搭載して自律推進できる自律車両、自律ロボット、自律ドローンなどの何れかであってもよい。推進装置の推進は、推進装置の使用者によって制御されてもよく、推進装置は、使用者に対して必要に応じて指示または警告を通知してもよい。一方、推進装置は、推進装置の推進を推進装置が自動制御するように構成されてもよい。
　セキュリティ部１３１０および１３２６は、例えば、画像データを保護するための演算を実行するセキュリティ演算部をそれぞれ備えてもよい。従って、セキュリティ部１３１０および１３２６は、セキュリティ演算部によって、暗号化演算や、復号演算、ハッシュ値演算、メッセージ認証コード演算、デジタル署名演算、ID（identification）認証、ファームウエア測定、暗号化セッション鍵確立、鍵交換、鍵更新などの何れかを処理することができる。
　一方、セキュリティ部１３１０および１３２６、ナンス更新部１３０９、メッセージカウンタ１３０８、並びにデータ検証部１３２５の何れかは、メモリと電気的に直接接続された構成とすることができる。このメモリはレジスタと電気的に直接接続されていてもよく、セキュリティ部１３１０および１３２６、ナンス更新部１３０９、メッセージカウンタ１３０８、並びにデータ検証部１３２５の何れかは、レジスタと電気的に直接接続されていてもよい。メモリは、メモリ内情報の漏洩または改竄の何れかから保護されたメモリであってもよい。このようなメモリおよびレジスタが、それぞれ記憶部１３０７および１３２４として用いられる。
　記憶部１３０７および１３２４には、鍵情報（例えば、事前共有鍵、秘密鍵、公開鍵、またはセッション鍵）や、証明書（例えば、ルート証明書、中間証明書、またはリーフ証明書）、暗号アルゴリズム情報などの何れかが格納されてもよい。記憶部１３０７および１３２４には、イメージセンサ１２１１またはアプリケーションプロセッサ１２１２の機能情報や、イメージセンサ１２１１またはアプリケーションプロセッサ１２１２のID情報（例えば、ソースIDや、目的地ID、最終目的地IDなど）、イメージセンサ１２１１またはアプリケーションプロセッサ１２１２のファームウエア情報などの何れかが格納されてもよい。記憶部１３０７および１３２４には、後述するセッション情報（例えば、セッションID）や、セキュリティ演算部の演算値（例えば、初期値、中間値、または最終値）、初期化ベクトル、ナンス値、メッセージカウント値、フレーム番号（フレームカウント値）などの何れかが格納されてもよい。
　セキュリティ部１３１０および１３２６、ナンス更新部１３０９、メッセージカウンタ１３０８、並びにデータ検証部１３２５の何れかは、例えば、イメージセンサ１２１１またはアプリケーションプロセッサ１２１２が、複数回のナンス値や、カウント値、完全性演算値、暗号化情報などの何れかを、記憶部１３０７または１３２４へ保存することによって、不具合の有無を判断することが可能になり、それに応じた対処（例えば、不具合個所のデータ再送の要求、異常メッセージの送信）も可能になる。また、ナンス値や、カウント値、完全性演算値、暗号化情報などの何れかが、保護された記憶部１３０７または１３２４へ定期的に保存される場合、仮に移動体装置の事故が発生した際に、保護された記憶部１３０７または１３２４が解析されることによって、事故発生の原因を特定しやすくなる効果もある。
　＜セッション＞
　リクエスタおよびレスポンダは、つまりアプリケーションプロセッサ１２１２およびイメージセンサ１２１１は、セッションによって１つ以上の通信チャネルを持つことができる。以下では、アプリケーションプロセッサ１２１２がリクエスタであって、イメージセンサ１２１１がレスポンダである構成を例に用いてセッションについて説明を行う。もちろん、アプリケーションプロセッサ１２１２がレスポンダであって、イメージセンサ１２１１がリクエスタであってもよい。
　また、リクエスタおよびレスポンダは、一時的に固定した暗号化情報を用いて安全な通信チャネルを構築できる。具体的には、セッションは、暗号化またはメッセージ認証のいずれか、または両方を提供する。セッションは、例えば、セッションハンドシェイク段階、アプリケーション段階、およびセッションターミネーション段階の３段階を含む。
　セッションハンドシェイク段階は、例えば、リクエスタからの鍵交換要求（PSK_EXCHANGEまたはKEY_EXCHANGEのいずれか）によって始まり、セッション秘密や暗号化鍵などセッション鍵を導出し、セッション鍵を用いて通信を保護する。この段階の目的は、例えば、いずれかの側がアプリケーションデータ（例えば、画像データ）を送信する前に、まずレスポンダとリクエスタとの間で信頼を構築することができる。さらに、ハンドシェイクのある程度の完全性と、導出されたハンドシェイク秘密との同期性とを保証してもよい。
　セッションは、この段階でエラーが発生する場合、直ちに終了してセッション終了へ進んでもよい。ハンドシェイクが成功すると、例えば、レスポンダからのフィニッシュ応答（FINISH_RSPまたはPSK_FINISH_RSP）によって終了し、アプリケーション段階が始まる。セッションは、一度ハンドシェイクが完了し、全ての検証に合格すると、レスポンダとリクエスタとのいずれかがアプリケーションデータを送信してもよいアプリケーション段階へ到達する。
　アプリケーション段階は、例えば、リクエスタからエンド要求（END_SESSION）が発行される場合に、またはエラーが発生する場合に終了する。次の段階は、セッションターミネーション段階となる。
　セッションターミネーション段階は、例えば、単なる内部段階であり、送信または受信される明示的なメッセージはない。リクエスタおよびレスポンダの両方は、セッションが終了するとき、導出した全てのセッション秘密や暗号化鍵などのセッション鍵を破棄またはクリーンアップする。リクエスタおよびレスポンダには、このセッションに関連付けられた他の内部データがあってもよく、それらもクリーンアップを望んでよい。
　セッション秘密は、例えば、AEAD（Authenticated Encryption with Additional Data）関数内で用いられる暗号化鍵およびソルトを導出するために用いられる。暗号化鍵の導出は、RFC5869で説明されるRFC2104およびHKDF-Expandで定義されているようにHMACを頻繁に用いてもよい。セッション秘密は、単一の秘密または複数種類の秘密で構成されてもよい。セッション鍵は、単一の鍵または複数種類の鍵で構成されてもよい。
　＜高速データ送信および低速コマンド送信の処理例＞
　図７８乃至図８０を参照して、イメージセンサ１２１１とアプリケーションプロセッサ１２１２との間で、高速データ送信および低速コマンド送信が行われる通信処理について説明する。
　図７８は、通信処理の第１の処理例を説明するフローチャートである。
　ここで、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２は、CCIホスト（リクエスタ）およびCSI-2ホストとしての機能を備えている。イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４は、CCIデバイス（レスポンダ）およびCSI-2デバイスとしての機能を備えている。CCIホストは、CCIデバイスへ要求メッセージを送信し、その受信に応じてCCIデバイスはCCIホストへ応答メッセージを送信する。
　ステップＳ５０１において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、GET_VERSION要求およびVERSION応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２は、エンドポイントのSPDM（Security Protocol and Data Model）バージョンを取得する。
　ステップＳ５０２において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、GET_CAPABILITIES要求およびCAPABILITIES応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２は、エンドポイントのSPDM機能を取得する。
　ステップＳ５０３において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、NEGOTIATE_ALGORITHMS要求およびALGORITHMS応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２は、拡張モード対応CSI-2送信回路１３０４と暗号アルゴリズムを交渉する。
　ステップＳ５０４において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、PSK_EXCHANGE要求およびPSK_EXCHANGE_RSP応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２および拡張モード対応CSI-2送信回路１３０４は、セッション秘密や暗号化鍵などのCCI向けのセッション鍵を導出する。
　ステップＳ５０５において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、PSK_FINISH要求およびPSK_FINISH_RSP応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２がPSK（PSK：Pre-shared key）を知っていて、ステップＳ５０４で導出されたCCI向けのセッション鍵が正しいことをレスポンダへ証明する。
　ステップＳ５０６において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、PSK_EXCHANGE要求およびPSK_EXCHANGE_RSP応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２および拡張モード対応CSI-2送信回路１３０４は、セッション秘密や暗号化鍵などのCSI-2向けのセッション鍵を導出する。
　ステップＳ５０７において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、PSK_FINISH要求およびPSK_FINISH_RSP応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２がPSK（PSK：Pre-shared key）を知っていて、ステップＳ５０６で導出されたCSI-2向けのセッション鍵が正しいことをレスポンダへ証明する。
　ここで、ステップＳ５０５およびＳ５０７におけるセッション鍵の証明は、リクエスタのfinished_keyと、このセッションのメッセージとで計算されたMAC値によって実現される。そして、ステップＳ５０４およびＳ５０６で導出したセッション鍵を用いて、以降のCCI通信およびCSI-2通信が保護される。
　ステップＳ５０８において、拡張モード対応CSI-2受信回路１３２２では、CCIホストからCSI-2ホストに対して、CSI-2向けセッション秘密やセッション鍵、アルゴリズム、その他のパラメータなどが供給される。
　ステップＳ５０９において、拡張モード対応CSI-2送信回路１３０４では、CCIデバイスからCSI-2デバイスに対して、CSI-2向けセッション秘密やセッション鍵、アルゴリズム、その他のパラメータなどが供給される。
　ステップＳ５１０において、拡張モード対応CSI-2送信回路１３０４のCSI-2デバイスは、拡張モード対応CSI-2受信回路１３２２のCSI-2ホストへ、高速データ通信による画像データの送信を行う。例えば、高速データ通信は、CSI-2向けセッション鍵を更新するタイミングとなるまで、継続して行われる。
　ステップＳ５１１において、拡張モード対応CSI-2受信回路１３２２では、CSI-2ホストからCCIホストに対して、CSI-2向けセッション鍵を更新するトリガが供給される。ただし、CSI-2デバイスまたはCCIデバイスからCCIホストに対してトリガが供給されたり、CCIホストからCCIホストに対して自己トリガが供給されたりしてもよい。
　ステップＳ５１２において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、KEY_UPDATE要求およびKEY_UPDATE_ACK応答が行われる。これにより、セッション鍵が更新され、古いセッション鍵の一部が破棄される。なお、セッション鍵が複数種類の鍵（要求方向鍵や応答方向鍵など）で構成される場合、その一部または全部が更新されてもよい。また、KEY_UPDATE要求は、後述のGET_ENCAPSULATED_REQUESTメカニズムを用いてレスポンダから発行されてもよい。
　ステップＳ５１３において、ステップＳ５１２と同様の処理が行われ、KEY_UPDATE要求およびKEY_UPDATE_ACK応答が２回行われる。これにより、ステップＳ５１２の処理だけでは破棄されなかった古いセッション鍵の残り（全部）が破棄される。
　ステップＳ５１４において、拡張モード対応CSI-2受信回路１３２２では、CCIホストからCSI-2ホストに対して、CSI-2向けセッション秘密やセッション鍵（更新後）、アルゴリズム、その他のパラメータなどが供給される。
　ステップＳ５１５において、拡張モード対応CSI-2送信回路１３０４では、CCIデバイスからCSI-2デバイスに対して、CSI-2向けセッション秘密やセッション鍵（更新後）、アルゴリズム、その他のパラメータなどが供給される。
　ステップＳ５１６において、ステップＳ５１０と同様に、高速データ通信による画像データの送信が開始され、以下、ステップＳ５１０乃至Ｓ５１５と同様の処理が繰り替えして行われる。
　なお、通信処理の第１の処理例では、CCI向けのセッション鍵とCSI-2向けのセッション鍵とが異なるものとなっており、CCI向けとCSI-2向けとでセッションIDが異なり、CCI向けとCSI-2向けとでセッション秘密が異なるものとなっている。これに限られることなく、通信処理の第２の処理例のように、CCI向けのセッション鍵とCSI-2向けのセッション鍵とが同一のものとなっていてもよく、CCI向けとCSI-2向けとでセッションIDを同一とし、CCI向けとCSI-2向けとでセッション秘密が同一としてもよい。
　図７９は、通信処理の第２の処理例を説明するフローチャートである。
　ステップＳ５２１乃至Ｓ５２３において、図７８のステップＳ５０１乃至Ｓ５０３と同様の処理が行われる。
　ステップＳ５２４において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、PSK_EXCHANGE要求およびPSK_EXCHANGE_RSP応答が行われる。ここで、通信処理の第２の処理例では、CCI向けのセッション秘密とCSI-2向けのセッション秘密とで同一のものが導出される。
　即ち、同一のセッション秘密から、CCI向けセッション鍵とCSI-2向けセッション鍵とを導出することができる。または、同一のセッション秘密から、アップリンク向けセッション鍵とダウンリンク（アップリンクの逆方向）向けセッション鍵とを導出してもよい。または、同一のセッション秘密から、CCI向けおよびCSI-2向けに共通なセッション鍵を導出してもよい。なお、CCI向けとCSI-2向けとでセッションが同一な場合でも、CCI向けとCSI-2向けとでセッション秘密やセッション鍵などが異なってもよい。
　その後、ステップＳ５２５乃至Ｓ５３４において、図７８のステップＳ５０７乃至Ｓ５１６と同様の処理が行われる。
　ここで、事前共有鍵PSK鍵交換スキームは、リクエスタおよびレスポンダが対称鍵暗号で相互認証およびセッション鍵確立を実行するためのオプションを提供する。このオプションは、非対称鍵暗号または証明書処理をサポートしないエンドポイントで特に役立つ。非対称鍵暗号がサポートされている場合でも、セッション鍵確立を迅速化するのに、このオプションも活用できる。このオプションは、リクエスタおよびレスポンダがハンドシェイクの前に共通のPSKを事前に知っている必要がある。
　基本的にPSKは、相互認証の資格情報およびセッション鍵確立のベースとして機能する。そのため、２つのエンドポイントと、２つのエンドポイントにPSKをプロビジョニングする潜在的に信頼されたサードパーティとだけが、PSKの値を知ってもよい。リクエスタは、複数のレスポンダとペアになってもよい。同様にレスポンダは、複数のリクエスタとペアになってもよい。リクエスタおよびレスポンダのペアは、１つ以上のPSKがプロビジョニングされてもよい。
　エンドポイントは、１つのデバイスに対するリクエスタとして動作し、同時に別のデバイスに対するレスポンダとして動作してもよい。トランスポート層は、PSKベースのセッション鍵交換が開始する前に、ピア（Peer）を識別し、２つのエンドポイント間の通信を確立する必要がある。
　PSKは、例えば安全な製造プロセス中など、信頼できる環境内でプロビジョニングされてもよい。PSKは、信頼できない環境では、安全なプロトコルを用いて２つのエンドポイント間で合意されてもよい。プロビジョニングされたPSKのサイズは、アプリケーションのセキュリティ強度の要件によって決まるが、128ビット以上にすべきで、256ビット以上が望ましい。PSKプロビジョニング中は、エンドポイント機能とサポートされているアルゴリズムとをピアへ通信してもよい。従って、PSKオプションを用いるセッション鍵確立中は、SPDMコマンドのGET_CAPABILITIESおよびNEGOTIATE_ALGORITHMSは必要ない。
　このオプションは、PSK_EXCHANGE/PSK_EXCHANGE_RSPおよびPSK_FINISH/PSK_FINISH_RSPの２つのメッセージペアが定義されている。PSK_EXCHANGEメッセージには、レスポンダへ特定のPSKを取得するように促す役割、リクエスタとレスポンダとの間でコンテキストを交換する役割、レスポンダが正しいPSKを知っており、正しいセッション鍵を導出したことをリクエスタへ証明する役割、の３つの役割がある。
　図８０は、通信処理の第３の処理例を説明するフローチャートである。
　ステップＳ５４１乃至Ｓ５４３において、図７８のステップＳ５０１乃至Ｓ５０３と同様の処理が行われる。
　ステップＳ５４４において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、GET_DIGESTS要求およびDIGESTS応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２は、拡張モード対応CSI-2送信回路１３０４から証明書チェインダイジェストを取得する。
　ステップＳ５４５おいて、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、GET_CERTIFICATE要求およびCERTIFICATE応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２は、拡張モード対応CSI-2送信回路１３０４から証明書チェインを取得する。なお、証明書チェインの取得が複数回実行されてもよい。
　ステップＳ５４６おいて、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、CHALLENGE要求およびCHALLENGE_AUTH応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２は、チャレンジ－レスポンスプロトコルを通じて拡張モード対応CSI-2送信回路１３０４を認証することができる。
　ステップＳ５４７において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、KEY_EXCHANGE要求（channel=CCI, sessionID=D）およびKEY_EXCHANGE_RSP応答が行われる。これにより、レスポンダ（または任意で両方のパーティ）の認証を目的としたリクエスタとレスポンダとの間のハンドシェイクが開始される。そして、最後のNEGOTIATE_ALGORITHMS / ALGORITHMS交換で交渉された内容に加えて暗号化パラメータが交渉され、共有鍵情報が確立される。
　ステップＳ５４８において、拡張モード対応CSI-2受信回路１３２２のCCIホストは、GET_ENCAPSULATED_REQUESTを拡張モード対応CSI-2送信回路１３０４のCCIデバイスに送信する。
　ステップＳ５４９において、拡張モード対応CSI-2送信回路１３０４のCCIデバイスは、ENCAPSULATED_REQUEST（GET_DIGESTS要求）を拡張モード対応CSI-2受信回路１３２２のCCIホストに送信する。
　ステップＳ５５０において、拡張モード対応CSI-2受信回路１３２２のCCIホストは、DELIVER_ENCAPSULATED_RESPONSE（DIGESTS応答）を拡張モード対応CSI-2送信回路１３０４のCCIデバイスに送信する。これにより、拡張モード対応CSI-2送信回路１３０４のCCIデバイスは、拡張モード対応CSI-2受信回路１３２２のCCIホストから証明書チェインダイジェストを取得する。
　ステップＳ５５１において、拡張モード対応CSI-2送信回路１３０４のCCIデバイスは、ENCAPSULATED_RESPONSE_ACK（GET_CERTIFICATE要求）を拡張モード対応CSI-2受信回路１３２２のCCIホストに送信する。
　ステップＳ５５２において、拡張モード対応CSI-2受信回路１３２２のCCIホストは、DELIVER_ENCAPSULATED_RESPONSE（CERTIFICATE応答）を拡張モード対応CSI-2送信回路１３０４のCCIデバイスに送信する。これにより、CCIデバイス（レスポンダ）は、CCIホスト（リクエスタ）から証明書チェインを取得してもよい。なお、この処理は、複数回実行されてもよい。
　ステップＳ５５３において、拡張モード対応CSI-2送信回路１３０４のCCIデバイスは、ENCAPSULATED_RESPONSE_ACKを拡張モード対応CSI-2受信回路１３２２のCCIホストに送信する。
　ステップＳ５５４において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、FINISH要求およびFINISH_RSP応答が行われる。これにより、ステップＳ５４７のKEY_EXCHANGE要求によって開始された、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間のハンドシェイクが完了される。
　ステップＳ５５５において、拡張モード対応CSI-2受信回路１３２２のCCIホストと拡張モード対応CSI-2送信回路１３０４のCCIデバイスとの間で、GET_MEASUREMENTS要求およびMEASUREMENTS応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２のCCIホストは、拡張モード対応CSI-2送信回路１３０４のCCIデバイスから測定データを取得する。なお、GET_MEASUREMENTS要求は、上述したGET_ENCAPSULATED_REQUESTメカニズムを用いてレスポンダから発行されてもよい。同様に、他の要求も上述したGET_ENCAPSULATED_REQUESTメカニズムを用いてレスポンダから発行されてもよい。
　その後、ステップＳ５５６では、ステップＳ５４７と同様にKEY_EXCHANGE要求（channel=CSI-2, sessionID=E）およびKEY_EXCHANGE_RSP応答が行われ、ステップＳ５５７では、ステップＳ５５４と同様にFINISH要求およびFINISH_RSP応答が行われる。そして、ステップＳ５５８乃至Ｓ５６６において、図７８のステップＳ５０８乃至Ｓ５１６と同様の処理が行われる。
　＜データ検証処理＞
　図８１乃至図８３を参照して、検証用パケットおよび被検証パケットを使用したデータ検証処理について説明する。
　図８１および図８２に示すように、拡張パケットは、パケットヘッダPH、拡張パケットヘッダePH、パケットデータ、拡張パケットフッタePF、およびパケットフッタPFで構成される。このような構成の拡張パケットにより、フレームスタート、埋込データ、画像データ、ユーザ定義データ、フレームエンド、書き込み命令（CCI Write）、読み出し命令（CCI Read）、および読み出し応答（CCI Read戻り値）を構成することができる。なお、パケットヘッダPH、拡張パケットヘッダePH、パケットデータ、拡張パケットフッタePF、およびパケットフッタPFは、その一部または全部を省略してもよい。即ち、拡張パケットヘッダePHおよびパケットデータを少なくとも含むパケット構成を拡張パケットと定義する。
　ところで、拡張パケットヘッダePH、パケットデータ、拡張パケットフッタePFの何れかは、ノイズや干渉や攻撃によって正常に受信されない（メッセージが消失する）可能性がある。そこで、拡張パケットフッタ末尾ePF0内は、拡張パケットヘッダePH、パケットデータ、および拡張パケットフッタ残りePF1の完全性を検証するための検証用パケットが格納されることが望ましい。完全性の検証は、例えば、誤り検出符号の一種である巡回冗長検査のCRC32が用いられる。また、CRC32の生成多項式は、例えばX32+X26+X23+X22+X16+X12+X11+X10+X8+X7+X5+X4+X2+X+1が用いられる。
　被検証パケットには、パケットデータを用いることができる。または、被検証パケットには、拡張パケットヘッダおよびパケットデータを用いることができる。または、被検証パケットには、パケットデータおよび拡張パケットフッタ残り（ePF1）を用いることができる。または、被検証パケットには、拡張パケットヘッダ、パケットデータおよび拡張パケットフッタ残り（ePF1）を用いることができる。このような被検証パケットにより、少なくともパケットデータが保護される。
　つまり、イメージセンサ１２１１は、パケットデータの第２保護データ（例えば、CRC演算値）を、セッション鍵を用いずに生成する第２保護部（例えば、CRC演算部）を備える。第２保護データは、例えば、高速データ送信の拡張パケットフッタePF内に格納される。つまり、フレームスタート内、埋込データ内、画像データ内、ユーザ定義データ内、フレームエンド内、書き込み命令（CCI Write）内、読み出し命令（CCI Read）内、読み出し応答（CCI Read戻り値）内などの何れかに格納される。
　拡張パケットフッタePF1やePF0は、セキュリティ機能（security feature）が定義されてもよい。つまり、イメージセンサ１２１１内にセキュリティ演算部（例えば、暗号演算部、復号演算部、ハッシュ値演算部、メッセージ認証コード演算部、デジタル署名演算部）を備えてもよい。そして、セキュリティ演算の結果（例えば、ハッシュ値、メッセージ認証コード、デジタル署名）が拡張パケットフッタePF内に格納されてもよい。
　セキュリティ演算の結果が格納されるのは、拡張パケットフッタePF0内ではなく拡張パケットフッタePF1内だけであってもよく、拡張パケットフッタ内ではなく拡張パケットフッタ外であってもよい（例えば、埋込データ内または読み出し応答内）。イメージセンサ１２１１が備えるセキュリティ演算部は、セキュリティ部１３１０に含まれる。
　メッセージ認証コード（MAC: Message Authentication Code）としては、GMAC（GaloisMAC）、CMAC（Cipher-based MAC）、HMAC（Hash-based MAC）などの何れかが用いられてもよい。例えば、AES（Advanced Encryption Standard）またはSHA（Secure Hash Algorithm）が適用された、AES-GMAC、AES-CMAC、SHA2-HMAC、SHA3-HMACなどの何れかが用いられてもよい。なお、AESのブロック長は128ビットであり、AESの鍵長は128ビット、192ビット、256ビットの何れかが選択される。
　拡張パケットフッタ内は、例えば、パケットデータを被検証パケットとして、または、拡張パケットヘッダおよびパケットデータを被検証パケットとして、ハッシュ（特に暗号学的ハッシュ）値、メッセージ認証コード、デジタル署名などの何れかのセキュリティ情報が格納されてもよい。その場合、攻撃者からの悪意ある改竄に対して、さらなる耐性を持たせることができる。なお、拡張パケットフッタ「ePF1」内または「ePF1およびePF0」内は、誤り検出符号の一種である巡回冗長検査のCRCが格納されてもよい。
　つまり、イメージセンサ１２１１が完全性演算部（例えば、第１保護部=セキュリティ演算部、第２保護部=CRC演算部）を備え、完全性を演算した結果である完全性演算値（例えば、第１保護データ、第２保護データ）が拡張パケットフッタ内に格納されてもよい。なお、CRCは、機能安全のために用いられることが可能で、その完全性はハードウェア障害が検出されないことを防ぐために用いられることが可能である。一方、セキュリティ機能の完全性は、意図的な干渉または攻撃を検出するために用いられることが可能である。つまり、セキュリティ演算部は、暗号に基づく完全性演算値を演算し、CRC演算部は、暗号に基づかない完全性演算値を演算する。
　アプリケーションプロセッサ１２１２は、例えば、検証用パケットを用いることで、被検証パケットの完全性を検証できる。異常と判断される場合、例えば、被検証パケットおよび検証用パケットを含むパケットの再送を要求する要求メッセージの送信、イメージセンサ１２１１に異常があるかをイメージセンサ１２１１へ問い合わせる要求メッセージの送信、イメージセンサ１２１１の一部または全部の機能の停止をイメージセンサ１２１１へ要求する要求メッセージの送信、推進装置の推進停止、推進装置の推進制御の変更、推進制御に用いる優先データの変更などの何れかの処理が実行されてもよい。
　なお、完全性演算値は、例えば、埋込データ内や、画像データ（パケットデータ）内、ユーザ定義データ内、書き込み命令内、読み出し命令内、読み出し応答などの内の何れかに格納されるようにしてもよい。その場合、完全性演算値は、拡張パケットフッタ内に格納されないようにしてもよい。例えば、完全性演算値は、画像のライン単位ではなく画像のフレーム単位で格納されるようにしてもよく、その場合は効率的に完全性が演算される。その場合、完全性演算値は、例えば、画像データが送信された後の埋込データ内または読み出し応答内に格納される。
　図８１のＡに示す拡張パケットは、拡張パケットヘッダePH、パケットデータ、および拡張パケットフッタ残りePF1を被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ末尾ePF0を検証用パケットとした構成例となっている。
　図８１のＢに示す拡張パケットは、パケットデータおよび拡張パケットフッタ残りePF1を被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ末尾ePF0を検証用パケットとした構成例となっている。
　図８１のＣに示す拡張パケットは、拡張パケットヘッダePHおよびパケットデータを被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ末尾ePF0を検証用パケットとした構成例となっている。
　図８１のＤに示す拡張パケットは、パケットデータを被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ末尾ePF0を検証用パケットとした構成例となっている。
　図８２のＡに示す拡張パケットは、拡張パケットヘッダePHおよびパケットデータを被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ残りePF1を検証用パケットとした構成例となっている。
　図８２のＢに示す拡張パケットは、拡張パケットヘッダePHおよびパケットデータを被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ残りePF1および拡張パケットフッタ末尾ePF0を検証用パケットとした構成例となっている。
　図８２のＣに示す拡張パケットは、パケットデータを被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ残りePF1を検証用パケットとした構成例となっている。
　図８２のＤに示す拡張パケットは、パケットデータを被検証パケットとして、その被検証パケットを用いたセキュリティ演算により求められる計算値が格納された拡張パケットフッタ残りePF1および拡張パケットフッタ末尾ePF0を検証用パケットとした構成例となっている。
　図８３は、アプリケーションプロセッサ１２１２において行われるデータ検証処理を説明するフローチャートである。
　ステップＳ６０１において、イメージセンサ１２１１から送信されてきた拡張パケットが拡張モード対応CSI-2受信回路１３２２により受信されると、セキュリティ部１３２６は、その拡張パケットの被検証パケットを受信する。そして、セキュリティ部１３２６が、被検証パケットの受信を完了すると、処理はステップＳ６０２に進む。なお、被検証パケットの全部の受信が完了していなくても、セキュリティ演算の計算を開始可能な少なくとも一部（例えば、128ビット）の受信が完了していれば処理はステップＳ６０２に進んでもよい。その場合、被検証パケットの全部の受信が完了するまで、被検証パケットの残りが引き続き受信される。
　ステップＳ６０２において、セキュリティ部１３２６は、ステップＳ６０１で受信した被検証パケットの少なくとも一部を用いたセキュリティ演算により求められる計算値の計算を開始する。
　ステップＳ６０３において、セキュリティ部１３２６は、拡張モード対応CSI-2受信回路１３２２を介して、イメージセンサ１２１１から送信されてくる検証用パケットを受信する。そして、セキュリティ部１３２６は、検証用パケットの受信を完了して、その検証用パケットに格納されている受信値（イメージセンサ１２１１で計算された計算値）を取得すると処理はステップＳ６０４に進む。
　ステップＳ６０４において、セキュリティ部１３２６は、ステップＳ６０２で開始した被検証パケットを用いたセキュリティ演算により求められる計算値の計算が完了（即ち、被検証パケットの全部を受信して、その全部を用いた計算が完了）すると、処理はステップＳ６０５に進む。
　ステップＳ６０５において、セキュリティ部１３２６は、ステップＳ６０３で受信した受信値と、ステップＳ６０４で求めた計算値とが一致したか否かを判定する。
　ステップＳ６０５において、セキュリティ部１３２６が、受信値と計算値とが一致したと判定した場合、処理はステップＳ６０６に進む。この場合、ステップＳ６０６において、セキュリティ部１３２６は、拡張モード対応CSI-2受信回路１３２２が受信した拡張パケットは正常であると判断し、処理は終了される。
　一方、ステップＳ６０５において、セキュリティ部１３２６が、受信値と計算値とが一致しないと判定した場合、処理はステップＳ６０７に進む。この場合、ステップＳ６０７において、セキュリティ部１３２６は、拡張モード対応CSI-2受信回路１３２２が受信した拡張パケットに異常が発生したと判断し、処理は終了される。
　＜メッセージカウント値を利用した機能安全の確保＞
　イメージセンサ１２１１は、機能安全（例えば、メッセージ欠落を検出して適切に処置すること）を確保するために、メッセージカウンタ１３０８がカウントするメッセージカウント値を、拡張パケットヘッダ内または拡張パケットフッタ内に格納することができる。例えば、イメージセンサ１２１１が備えるメッセージカウンタ１３０８は、イメージセンサ１２１１からメッセージが送信されるたびにインクリメントまたはデクリメントされたメッセージカウント値を格納することができる。なお、イメージセンサ１２１１は、仮想チャネル（バーチャルチャネル）ごとに独立したメッセージカウンタ１３０８を設ける構成や、仮想チャネルで共通なメッセージカウンタ１３０８を設ける構成としてもよい。
　メッセージカウンタ１３０８は、ある仮想チャネルの拡張パケットヘッダを含む最初のパケットにおいてメッセージカウント値を初期値（例えば、０または最大値）に設定し、ある仮想チャネルの拡張パケットヘッダを含むデータを送信するたびにメッセージカウント値をインクリメントまたはデクリメントする。また、メッセージカウンタ１３０８は、例えば、拡張パケットヘッダを含まないデータが送信される場合、メッセージカウント値をインクリメントまたはデクリメントせずに、次に拡張パケットヘッダを含むデータが送信されたときに、カウントを再開する。
　メッセージカウンタ１３０８は、フレームスタートまたはフレームエンドに関わらずカウントを継続してもよい。そして、メッセージカウンタ１３０８は、メッセージカウント値が規定値（例えば、最大値または０）までカントされた場合、次のメッセージカウント値を初期値（例えば、０または最大値）に戻して、カウントを行う。なお、拡張パケットヘッダの一部は、ナンス値の一部が格納されてもよい。
　なお、メッセージカウント値を受信する受信側（イメージセンサ１２１１またはアプリケーションプロセッサ１２１２）は、メッセージが欠落した場合には、その欠落を即座に検知することができる。例えば、膨大な量のメッセージを意図的に混入させることでイメージセンサ１２１１またはアプリケーションプロセッサ１２１２の可用性を侵害するDoS（Denial-of-service）攻撃なども、受信側において即座に検知される。このため、メッセージカウント値は、拡張パケットヘッダ内に格納されることが望ましい。このような欠落や攻撃などを、より短時間で検出することができるようにすることで、受信側は、それらに対する対応を短い時間で開始することができ、例えば、高速移動または高速可動が可能な推進装置にとっては特に好適である。
　なお、書き込み命令（CCI Write）、読み出し命令（CCI Read）、または読み出し応答（CCI Read戻り値）についても、メッセージカウント値または完全性演算値が格納されるように構成されてもよく、拡張パケットに関連する要素が適用されてもよい。その場合、書き込み命令、読み出し命令、または読み出し応答についても、機能安全に対応することや完全性を保護することなどが可能になる。
　図８４は、イメージセンサ１２１１がメッセージカウント値を送信するメッセージカウント値送信処理を説明するフローチャートである。
　ステップＳ６１１において、メッセージカウンタ１３０８は、メッセージカウント値を初期化して０に設定する。
　ステップＳ６１２において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットヘッダを送信するか否かを判定し、拡張パケットヘッダを送信すると判定されるまで処理は待機される。そして、ステップＳ６１２において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットヘッダを送信すると判定した場合、処理はステップＳ６１３に進む。
　ステップＳ６１３において、拡張モード対応CSI-2送信回路１３０４は、メッセージカウンタ１３０８からメッセージカウント値を取得し、拡張パケットヘッダに格納する。
　ステップＳ６１４において、拡張モード対応CSI-2送信回路１３０４は、ステップＳ６１３でメッセージカウント値を格納した拡張パケットヘッダを送信する。
　ステップＳ６１５において、メッセージカウンタ１３０８は、メッセージカウント値が最大値までカウントされたか否かを判定する。ステップＳ６１５において、メッセージカウンタ１３０８が、メッセージカウント値が最大値までカウントされていないと判定した場合、処理はステップＳ６１６に進む。
　ステップＳ６１６において、メッセージカウンタ１３０８は、メッセージカウント値をインクリメントする。その後、処理はステップＳ６１２に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ６１５において、メッセージカウンタ１３０８が、メッセージカウント値が最大値までカウントされたと判定した場合、処理はステップＳ６１１に戻ってメッセージカウント値が初期化された後、以下、同様の処理が繰り返して行われる。
　なお、このようにメッセージカウント値をインクリメントする他、例えば、メッセージカウント値を初期化して最大値に設定して、デクリメントを行ってもよい。
　＜埋め込みデータについて＞
　図８５乃至図８８を参照して、埋め込みデータについて説明する。
　イメージセンサ１２１１は、埋込データを用いることで、データストリーム内にデバイス設定情報などの追加情報を含めることができる。埋込データは、１つ以上のライン（行）で構成され、イメージセンサ１２１１の構成データや、規格に従うレジスタ値、ベンダ固有のレジスタ値、フレーム形式の説明、統計値などの何れかを含むことが可能である。
　図８５のＡには、１つのラインの埋込データが示されており、埋め込みデータフォーマットコードに続いて、所望のデータ量の埋め込みデータが連続して配置され、その残りにパディングキャラクタが配置された構成となっている。
　埋込データには、画像データまたはユーザ定義データに関連する情報が含まれる。このため、画像データまたはユーザ定義データは圧縮されたデータであってもよいが、埋込データは、圧縮されてないデータ（非圧縮データ）であることが望ましい。従って、データの圧縮が用いられる場合、高速データ送信のフレーム内には、圧縮データ（画像データまたはユーザ定義データ）と非圧縮データ（埋込データ）とが混在することになる。
　埋込データは、埋込データへ追加されるレジスタ値の数に応じて、埋込データのライン（行）を複数設けることが可能である。また、埋込データの行数は、フレーム内で最初の埋込データ行におけるフレーム形式内の説明の一部によって指定されることが可能である。埋込データのライン長は、画像データまたはユーザ定義データのライン長より短くてもよいが、画像データまたはユーザ定義データのライン長を超えることは好ましくなく、画像データまたはユーザ定義データのライン長と同一であることが望ましい。埋込データの最初のピクセル値は、埋込データに用いられる形式を示してもよい。
　ナンス値の一部または全部は、図８５のＢに示すようなベンダ固有コード（Vendor specific）またはリザーブドコード（Reserved for future use）を示す埋込データの少なくとも一部内へ格納されて送信されてもよい。フレーム内において埋込データは、フレームスタートと最初の画像データまたはユーザ定義データとの間、および、最後の画像データまたはユーザ定義データとフレームエンドとの間の何れかに格納される。ただし、最後の画像データまたはユーザ定義データとフレームエンドとの間の埋込データは省略してもよい。
　図８６には、イメージセンサ１２１１から送信される２フレーム分の画像データのデータ構造の一例が示されている。
　図８６に示すように、第１のバーチャルチャネルのフレームスタート（VC1 FS）が送信された後、読み出し命令および読み出し応答に続いて、第２のバーチャルチャネルのフレームスタート（VC2 FS）が送信される。次に、第１のバーチャルチャネルの第１の埋め込みデータ（VC1 Emb Data）および第２のバーチャルチャネルの第１の埋め込みデータ（VC2 Emb Data）が送信される。そして、１フレーム分の第１のバーチャルチャネルの画像データ（VC1 Img Data）および第２のバーチャルチャネルのユーザ定義データ（VC2 UD Data）が送信される。１フレーム分の送信が完了すると、第１のバーチャルチャネルの第２の埋め込みデータ（VC1 Emb Data）および第２のバーチャルチャネルの第２の埋め込みデータ（VC2 Emb Data）が送信される。その後、第１のバーチャルチャネルのフレームエンド（VC1 FE）が送信された後、読み出し命令および読み出し応答に続いて、第２のバーチャルチャネルのフレームエンド（VC2 FE）が送信される。
　図８６では、第１のバーチャルチャネルと第２のバーチャルチャネルとでメッセージカウント値が共通化される例が示されている。このとき第１のバーチャルチャネルと第２のバーチャルチャネルとで独立したセージカウンタが設けられる構成としてもよい。また、ユーザ定義データは、画像データなどであってもよい。
　ここで、ナンス値の一部または全部は、例えば、フレームスタートからフレームエンドまでの期間内、またはフレームエンドからフレームスタートまでの期間内（フレームブランキング期間）に格納される。また、フレームスタートからフレームエンドまでの期間内でナンス値を格納できるのは、例えば、埋込データ内、画像データ内、非画像データ内、およびラインブランキング期間内の何れかである。また、第２のバーチャルチャネルに格納されてもよい。
　フレームスタートおよびフレームエンドを定義することによって、例えば、高速データ送信の開始および終了をイメージセンサからプロセッサへ通知することが可能となる。また、イメージセンサは、フレーム送信周期を一定に保つことが可能となる。なお、埋込データは、画像データを表す属性や画像データに関連する情報（メタデータ）などが格納されるデータである。
　本実施の形態では、画像データの高速データ送信を阻害せずに、ナンス値の高速データ送信が実行される例を説明する。つまり、画像データの高速データ送信とナンス値の高速データ送信とが、並列実行ではなく直列実行される例を説明する。ただし、画像データの高速データ送信とナンス値の送信（高速データ送信または低速コマンド送信）とで通信経路が異なる場合、並列実行されてもよい。
　なお、高速データ送信と低速コマンド送信とは、フィルタによる周波数分離が可能なので、消費電力に問題なければ、送信の一部または全部が重複（並列実行）されていても構わない。ナンス値の一部または全部は、複数フレームごとに送信されてもよいが、例えばフレーム欠落などの理由によって、１フレームごとに送信される方が望ましい。例えば、フレームスタート（Frame Start；FS）パケットはFrame Start Code（Data Type = 0x00）を含み、フレームエンド（Frame End；FE）パケットはFrame End Code（Data Type = 0x01）を含む。
　図８７は、イメージセンサ１２１１が画像データを送信する画像データ送信処理を説明するフローチャートである。
　ステップＳ６２１において、拡張モード対応CSI-2送信回路１３０４は、高速データ送信の開始命令を受信したか否かを判定し、高速データ送信の開始命令を受信したと判定されるまで、処理が待機される。そして、ステップＳ６２１において、拡張モード対応CSI-2送信回路１３０４が、高速データ送信の開始命令を受信したと判定した場合、処理はステップＳ６２２に進む。
　ステップＳ６２２おいて、画素１３０１が撮像を開始し、画素１３０１から出力される画像データが、AD変換器１３０２および画像処理部１３０３を介して拡張モード対応CSI-2送信回路１３０４に供給される。
　ステップＳ６２３において、拡張モード対応CSI-2送信回路１３０４は、第１のバーチャルチャネルのフレームスタートを送信する。
　ステップＳ６２４において、拡張モード対応CSI-2送信回路１３０４は、第２のバーチャルチャネルのフレームスタートを送信する。
　ステップＳ６２５において、拡張モード対応CSI-2送信回路１３０４は、第１のバーチャルチャネルの第１の埋め込みデータを送信する。
　ステップＳ６２６において、拡張モード対応CSI-2送信回路１３０４は、第２のバーチャルチャネルの第１の埋め込みデータを送信する。
　ステップＳ６２７おいて、拡張モード対応CSI-2送信回路１３０４は、第１のバーチャルチャネルの画像データを送信する。
　ステップＳ６２８において、拡張モード対応CSI-2送信回路１３０４は、第２のバーチャルチャネルのユーザ定義データを送信する。
　ステップＳ６２９において、拡張モード対応CSI-2送信回路１３０４は、１フレーム分の画像データの送信が完了したか否かを判定する。
　ステップＳ６２９において、拡張モード対応CSI-2送信回路１３０４が、１フレーム分の画像データの送信が完了していないと判定した場合、処理はステップＳ６２７に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ６２９において、拡張モード対応CSI-2送信回路１３０４が、１フレーム分の画像データの送信が完了したと判定した場合、処理はステップＳ６３０に進む。
　ステップＳ６３０において、拡張モード対応CSI-2送信回路１３０４は、第１のバーチャルチャネルの第２の埋め込みデータを送信する。
　ステップＳ６３１において、拡張モード対応CSI-2送信回路１３０４は、第２のバーチャルチャネルの第２の埋め込みデータを送信する。
　ステップＳ６３２において、拡張モード対応CSI-2送信回路１３０４は、第１のバーチャルチャネルのフレームエンドを送信する。
　ステップＳ６３３において、拡張モード対応CSI-2送信回路１３０４は、第２のバーチャルチャネルのフレームエンドを送信する。
　ステップＳ６３４において、拡張モード対応CSI-2送信回路１３０４は、高速データ送信の終了命令を受信したか否かを判定する。
　ステップＳ６３４において、拡張モード対応CSI-2送信回路１３０４が、高速データ送信の終了命令を受信していないと判定した場合、処理はステップＳ６２２に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ６３４において、拡張モード対応CSI-2送信回路１３０４が、高速データ送信の終了命令を受信したと判定した場合、処理は終了される。
　撮像開始は、高速データ送信の終了命令を受信するまで継続実行されてもよく、高速データ送信の開始命令を受信するたびに実行されてもよい。
　図８８は、イメージセンサ１２１１が完全性演算値を送信する完全性演算値送信処理を説明するフローチャートである。
　ステップＳ６４１において、セキュリティ部１３１０は、第１のバーチャルチャネルのセッション鍵を導出する。
　ステップＳ６４２において、セキュリティ部１３１０は、第２のバーチャルチャネルのセッション鍵を導出する。
　ステップＳ６４３において、メッセージカウンタ１３０８は、メッセージカウント値の上位カウント値を初期化して０に設定する。
　ステップＳ６４４において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値を初期化して０に設定する。
　ステップＳ６４５において、拡張モード対応CSI-2送信回路１３０４は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ６４６に進む。
　ステップＳ６４６において、拡張モード対応CSI-2送信回路１３０４は、第１のバーチャルチャネルの拡張パケットを送信するか否かを判定する。
　ステップＳ６４６において、拡張モード対応CSI-2送信回路１３０４が、第１のバーチャルチャネルの拡張パケットを送信しないと判定した場合、処理はステップＳ６４５に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ６４６において、拡張モード対応CSI-2送信回路１３０４が、第１のバーチャルチャネルの拡張パケットを送信すると判定した場合、処理はステップＳ６４７に進む。
　ステップＳ６４７において、セキュリティ部１３１０は、ステップＳ６４１で導出した第１のバーチャルチャネルのセッション鍵を用いて、第１のバーチャルチャネルの完全性演算値を演算する。
　ステップＳ６４８において、拡張モード対応CSI-2送信回路１３０４は、ステップＳ６４７で算出された完全性演算値を第１のバーチャルチャネルの拡張パケットに配置し、その第１のバーチャルチャネルの拡張パケットを送信する。
　ステップＳ６４９において、拡張モード対応CSI-2送信回路１３０４は、第２のバーチャルチャネルの拡張パケットを送信するか否かを判定し、第２のバーチャルチャネルの拡張パケットを送信と判定されるまで処理を待機する。そして、ステップＳ６４９において、拡張モード対応CSI-2送信回路１３０４が、第２のバーチャルチャネルの拡張パケットを送信すると判定した場合、処理はステップＳ６５０に進む。
　ステップＳ６５０において、セキュリティ部１３１０は、ステップＳ６４２で導出した第２のバーチャルチャネルのセッション鍵を用いて、第２のバーチャルチャネルの完全性演算値を演算する。
　ステップＳ６５１において、拡張モード対応CSI-2送信回路１３０４は、ステップＳ６５０で算出された完全性演算値を第２のバーチャルチャネルの拡張パケットに配置し、その第２のバーチャルチャネルの拡張パケットを送信する。
　ステップＳ６５２において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値が最大値までカウントされたか否かを判定する。
　ステップＳ６５２において、メッセージカウンタ１３０８が、メッセージカウント値の下位カウント値が最大値までカウントされていないと判定した場合、処理はステップＳ６５３に進む。ステップＳ６５３において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値をインクリメントした後、処理はステップＳ６４５に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ６５２において、メッセージカウンタ１３０８が、メッセージカウント値の下位カウント値が最大値までカウントされたと判定した場合、処理はステップＳ６５４に進む。ステップＳ６５４において、メッセージカウンタ１３０８は、メッセージカウント値の上位カウント値をインクリメントした後、処理はステップＳ６４４に戻り、以下、同様の処理が繰り返して行われる。
　そして、ステップＳ６４５において、拡張モード対応CSI-2送信回路１３０４が、セッションを終了すると判定した場合、処理はステップＳ６５５に進む。
　ステップＳ６５５において、セキュリティ部１３１０は、第１のバーチャルチャネルのセッション鍵と第２のバーチャルチャネルのセッション鍵とを破棄またはクリーンアップし、その後、処理は終了される。
　＜画像データのデータ構造の変形例＞
　図８９乃至図９１を参照して、画像データのデータ構造について説明する。
　図８９には、画像データのデータ構造の第１の変形例が示されている。
　図８９に示す画像データのデータ構造では、第１のバーチャルチャネルおよび第２のバーチャルチャネルで共通化されたメッセージカウント値が用いられている。
　ただし、セッション鍵またはメッセージカウンタは、第１のバーチャルチャネルおよび第２のバーチャルチャネルで共通化されてもよい。また、画像データまたは埋込データは、他データへ置き換えられてもよい。例えば、埋込データは、画像データへ置き換えられてもよい。一方、メッセージカウンタは、仮想チャネル（VC）を跨いでカウントすることによって、共通化されてもよい。
　図９０には、画像データのデータ構造の第２の変形例が示されている。
　図９０に示す画像データのデータ構造では、Write（CCI書き込み命令）、Read1（CCI読み出し命令）、およびRead2（CCI読み出し応答）で、それぞれ独立したメッセージカウント値が用いられている。
　図９１には、画像データのデータ構造の第３の変形例が示されている。
　図９１に示す画像データのデータ構造では、CCIアップリンク（WriteおよびRead1）およびCCIダウンリンク（Read2）で、それぞれ独立したメッセージカウント値が設けられている。つまり、メッセージカウント値は、Write（CCI書き込み命令）とRead1（CCI読み出し命令）とで共通化されてもよい。
　＜ナンス値について＞
　ナンス値は、例えば、同じセッション鍵に対してnumber used onceであるため、セッション鍵を用いる暗号化演算または復号演算の初期化ベクトル（initialization vector）の一部または全部として用いられる。そのため、イメージセンサ１２１１が暗号化演算に用いたナンスが、イメージセンサ１２１１から送信されてアプリケーションプロセッサ１２１２で受信されることによって、アプリケーションプロセッサ１２１２は復号演算に必要なナンス値を入手できる。
　つまり、イメージセンサ１２１１は、画像データを送信する前にナンス値を送信することが望ましい。具体的には、あるフレーム内の画像データに対応するナンス値の一部または全部は、１つ前にフレーム内の最後の画像データが送信完了された後から、あるフレーム内の最初の画像データが送信開始される前までの、読み出し応答内や、ユーザ定義データ内、埋込データ内（画像データ直後）、フレームエンド内、フレームスタート内、埋込データ内（画像データ直前）などの何れかに格納される。
　例えば、低速コマンド送信のマスタであるアプリケーションプロセッサ１２１２は、低速コマンド送信のスレーブであるイメージセンサ１２１１から高速データ送信によって送信されたフレームスタートや、埋込データ、画像データ、ユーザ定義データ、フレームエンドなどの何れかの受信開始または受信完了に応じて、イメージセンサ１２１１内のナンス値をアプリケーションプロセッサ１２１２へ読み出すことを要求する読み出し命令を低速コマンド送信によって送信してもよい。
　イメージセンサ１２１１は、アプリケーションプロセッサ１２１２から送信された読み出し命令を受信し、それに応じたナンス値を高速データ送信によって送信する。そして、アプリケーションプロセッサ１２１２が読み出し応答を受信することによって、イメージセンサ１２１１からアプリケーションプロセッサ１２１２へナンス値を通知できる。
　イメージセンサ１２１１から通知されたナンス値はアプリケーションプロセッサ１２１２内で用いられるので、ナンス値の一部または全部は、フレームエンドと次のフレームスタートとの間の画像データが送信されないフレームブランキングの期間内に送信されることが望ましい。ただし、最初のフレーム（Frame Number = 1）については、イメージセンサ１２１１とアプリケーションプロセッサ１２１２とで最初のナンス値（初期値）を事前合意しておくか、最初のナンス値の一部または全部が画像データの送信開始までにアプリケーションプロセッサ１２１２で受信されてれいればよい。
　この読み出し命令は、例えば、I2CまたはI3Cの規格におけるRead/WriteのReadに相当する。一方、読み出し応答は、Read戻り値に相当する。なお、読み出し応答のタイミングを調整するために、アプリケーションプロセッサ１２１２が高速データ送信を受信してから、読み出し命令を送信するまでの間に、所定時間を待機するタイマが設けられてもよい。
　＜I2CおよびI3Cについて＞
　I2CバスまたはI2Cバスと呼ばれる場合もある集積回路間シリアルバスは、低速周辺装置をアプリケーションプロセッサ１２１２に接続する際に使用することを意図していたシリアルシングルエンドコンピュータバスである。I2Cバスは、I2Cバス上で送信される様々なメッセージに対して、各デバイスがマスタおよびスレーブとして働くことができるマルチマスタバスである。
　I2Cバスは、シリアルデータライン(SDA)およびシリアルクロックライン(SCL)を含む２つの双方向オープンドレインコネクタのみを使用して、データを送信することができる。それらのコネクタは通常、プルアップ抵抗器によって終端される信号線を含む。I2Cバスの動作を管理するプロトコルは、メッセージの基本タイプを規定し、それらのメッセージはそれぞれSTARTで開始し、STOPで終了する。I2Cバスは7ビットアドレス指定を使用し、２つのタイプのノードを規定する。
　マスタノードは、クロックを生成し、スレーブノードとの通信を開始するノードである。スレーブノードは、クロックを受信し、マスタによってアドレス指定されたときに応答するノードである。I2Cバスはマルチマスタバスであり、それは、任意の数のマスタノードが存在できることを意味する。さらに、マスタとスレーブの役割は、メッセージ間で(すなわち、STOPが送られた後)変更される場合がある。カメラ実装である本実施の形態では、センサから画像を取り込み、そのような画像データをベースバンドプロセッサの中のメモリへ送信するために片方向送信が使用されてもよく、一方、ベースバンドプロセッサと、センサならびに他の周辺デバイスとの間で制御データが交換されてもよい。
　一例では、ベースバンドプロセッサとイメージセンサ（または1つもしくは複数のスレーブノード）との間のそのような制御データのために、カメラ制御インタフェース（CCI）プロトコルが使用される場合がある。一例では、CCIプロトコルは、イメージセンサとベースバンドプロセッサとの間のI2Cシリアルバスを介して実施されてもよい。従来のI2Cシステム、すなわちカメラ制御インターフェースベースのカメラシステムは、スレーブノードがバスを使用することを望むことを、スレーブノードがマスタノードへ示すことを可能にするために、スレーブデバイスごとに別個の割込み（IRQ）ラインを使用する。
　一方、Ｉ３Ｃの通信規格は、データを伝送するＳＤＡ線と、クロック信号を伝送するＳＣＬ線との２本の信号線を介して通信を行う規格である。この規格において、デバイス（プロセッサなど）は、マスタまたはスレーブとして動作するデバイスと、スレーブとしてのみ動作するデバイスとに分類される。例えば、プロセッサは、マスタまたはスレーブとして動作し、センサはスレーブとしてのみ動作する。
　ここで、マスタは、スレーブを制御するデバイスであり、スレーブは、マスタの制御に従って動作するデバイスである。また、Ｉ３Ｃでは１つのマスタに対して複数のスレーブを接続することができる。また、１つのスレーブに対して複数のマスタが信号を送信することができ、この通信を以下、「マルチマスタ通信」と称する。さらに、マスタを介さずにスレーブ同士で通信を行うことができ、この通信は、「ピアツーピア通信」と呼ばれる。また、スレーブは、他のデバイスの通信によりＳＤＡ線が通信中（ビジー）である間に、その通信に割り込んで通信を行うことができ、この割込みは、「帯域内割込み（In-Band Interrupt）」と呼ばれる。
　上述のマルチマスタ通信、帯域内割込み、および、ピアツーピア通信においては、複数のデバイスが同時に送信した信号がＳＤＡ線において衝突するおそれがある。例えば、マスタが、あるスレーブへ信号を送信している間に、別のスレーブが帯域内割込みを行ってマスタへ信号を送信すると、マスタからの信号とスレーブからの信号とが衝突してしまう。このため、Ｉ３Ｃにおけるデバイスは、衝突を検出してデバイス同士を調停する機能を有する。
　上述した割り込み機能を用いると、アプリケーションプロセッサ１２１２と簡単に同期をとれるので、イメージセンサ１２１１が決めるタイミングで割り込み実行することによって、イメージセンサ１２１１が決めるタイミングに応じてナンス関連情報が送信される。ただし、イメージセンサ１２１１は、帯域内割込みによって読み出し命令をトリガし、それに応じて読み出し応答を送信してもよいし、帯域内割込みによって読み出し命令を省略して読み出し応答を送信してもよい。
　＜完全性演算値処理＞
　図９２乃至図９５を参照して、完全性演算値処理について説明する。
　図９２は、イメージセンサ１２１１が完全性演算値を送信する完全性演算値処理の第１の処理例を説明するフローチャートである。
　ステップＳ６６１において、セキュリティ部１３１０は、セッション鍵を導出する。
　ステップＳ６６２において、メッセージカウンタ１３０８は、メッセージカウント値を初期化して０に設定する。
　ステップＳ６６３において、拡張モード対応CSI-2送信回路１３０４は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ６６４に進む。
　ステップＳ６６４において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信するか否かを判定する。
　ステップＳ６６４において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信しないと判定した場合、処理はステップＳ６６３に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ６６４において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信すると判定した場合、処理はステップＳ６６５に進む。
　ステップＳ６６５において、セキュリティ部１３１０は、メッセージカウント値を用いて、完全性演算値を演算する。
　ステップＳ６６６において、拡張モード対応CSI-2送信回路１３０４は、ステップＳ６６５で算出された完全性演算値を拡張パケットに配置し、その拡張パケットを送信する。
　ステップＳ６６７において、メッセージカウンタ１３０８は、メッセージカウント値が最大値までカウントされたか否かを判定する。ステップＳ６６７において、メッセージカウンタ１３０８が、メッセージカウント値が最大値までカウントされていないと判定した場合、処理はステップＳ６６８に進む。
　ステップＳ６６８において、メッセージカウンタ１３０８は、メッセージカウント値をインクリメントする。その後、処理はステップＳ６６３に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ６６７において、メッセージカウンタ１３０８が、メッセージカウント値が最大値までカウントされたと判定した場合、処理はステップＳ６６９に進む。ステップＳ６６９において、セキュリティ部１３１０は、セッション鍵を更新した後、処理はステップＳ６６２に戻り、以下、同様の処理が繰り返して行われる。
　そして、ステップＳ６６３において、拡張モード対応CSI-2送信回路１３０４が、セッションを終了すると判定した場合、処理はステップＳ６７０に進む。
　ステップＳ６７０において、セキュリティ部１３１０は、セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　このように、画像ラインごとのMAC値を演算して拡張パケットフッタ内に格納して送信する場合、メッセージカウント値は、拡張パケットを送信するごとに1ずつインクリメントされるので、216回でメッセージカウント値は一周する。例えば、フレームレートが60fpsで画素数4096×2160（横×縦）の4Kデータを送信する場合、フレームスタートと埋込データとフレームエンドとの3ラインを加算した2163ラインの拡張パケットを1フレーム内で送信することを想定すれば、(216)/(60×2163)≒0.5秒でメッセージカウント値が一周する。
　例えば、イメージセンサ１２１１が、同じセッション鍵で同じ初期化ベクトル値を用いてメッセージのGalois Message Authentication Code（GMAC）値などのMAC値を演算してメッセージおよびMAC値を送信する場合、攻撃者はメッセージおよびMAC値の連立方程式を計算することによってセッション鍵を簡単に入手できる。その場合、攻撃者は、MAC値を自由に改竄できるようになるため、メッセージの成りすまし、改竄、リプレイなどの攻撃が可能になる。そのため、メッセージカウント値を初期化ベクトルの可変部分、つまりナンス値として用いる場合、メッセージカウント値が一周するまでにセッション鍵を更新する必要がある。例えば、フレームブランキングまたはラインブランキングの期間を活用することによって、ナンス値が一周（ロールオーバー）するまでにセッション鍵が更新されればよい。
　図９３は、イメージセンサ１２１１が完全性演算値を送信する完全性演算値処理の第２の処理例を説明するフローチャートである。
　ステップＳ６８１において、セキュリティ部１３１０は、セッション鍵を導出する。
　ステップＳ６８２において、メッセージカウンタ１３０８は、メッセージカウント値の上位カウント値を初期化して０に設定する。
　ステップＳ６８３において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値を初期化して０に設定する。
　ステップＳ６８４において、拡張モード対応CSI-2送信回路１３０４は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ６８５に進む。
　ステップＳ６８５において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信するか否かを判定する。
　ステップＳ６８５において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信しないと判定した場合、処理はステップＳ６８４に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ６８５において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信すると判定した場合、処理はステップＳ６８６に進む。
　ステップＳ６８６において、セキュリティ部１３１０は、メッセージカウント値の上位カウント値および下位カウント値を用いて、完全性演算値を演算する。
　ステップＳ６８７において、拡張モード対応CSI-2送信回路１３０４は、ステップＳ６８６で算出された完全性演算値を拡張パケットに配置し、その拡張パケットを送信する。
　ステップＳ６８８において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値が最大値までカウントされたか否かを判定する。ステップＳ６８８において、メッセージカウンタ１３０８が、メッセージカウント値の下位カウント値が最大値までカウントされていないと判定した場合、処理はステップＳ６８９に進む。
　ステップＳ６８９において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値をインクリメントする。その後、処理はステップＳ６８４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ６８８において、メッセージカウンタ１３０８が、メッセージカウント値の下位カウント値が最大値までカウントされたと判定した場合、処理はステップＳ６９０に進む。ステップＳ６９０において、メッセージカウンタ１３０８は、メッセージカウント値の上位カウント値をインクリメントした後、処理はステップＳ６８３に戻り、以下、同様の処理が繰り返して行われる。
　そして、ステップＳ６８４において、拡張モード対応CSI-2送信回路１３０４が、セッションを終了すると判定した場合、処理はステップＳ６９１に進む。
　ステップＳ６９１において、セキュリティ部１３１０は、セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　このように、メッセージカウント値を初期化ベクトルの一部、つまりナンス値の一部（例えば、下位カウント値）として用いる場合、ナンス値の残り（例えば、上位カウント値）も併用することによって、セッション鍵の更新を不要にすること、または、セッション鍵の更新頻度を減らすことができる。
　例えば、フレームレートが60fpsで画素数4096×2160（横×縦）の4Kデータを送信する場合、ナンス値が一周するのは、
　・16ビット幅の上位カウント値を併用すると232÷60÷2163≒9時間
　・20ビット幅の上位カウント値を併用すると236÷60÷2163≒6日
　・24ビット幅の上位カウント値を併用すると240÷60÷2163≒98日
　・28ビット幅の上位カウント値を併用すると244÷60÷2163≒4年
　・32ビット幅の上位カウント値を併用すると248÷60÷2163≒69年となる。
　ここで、イメージセンサ１２１１またアプリケーションプロセッサ１２１２の電源が再起動（OFFの後にON）される場合、保護された画像データを再び送信する前に鍵交換が必要になるので、それに応じてセッション鍵は更新される。例えば、一般的な車載用途で６日以上も電源を再起動しない可能性は低く、４年以上も電源を再起動しない可能性は極めて低いので、上位カウント値は20～8ビット幅あれば十分である。もちろん、その限りではなく、それ以上のビット幅を用いてもよい。
　例えば、給油式の車両であれば給油の際に電源OFFとすればよく、給油式または充電式の車両であっても車両点検の際に電源OFFとすれば、保護された画像データを再び送信する前に鍵交換が必要になるので、それに応じてセッション鍵は更新される。例えば、IoT（Internet of ThingsまたはIntelligence of Things）向けイメージセンサが想定される場合、電源が再起動されないことも想定されるので、上位カウント値は32ビット幅あれば十分である。もちろん、その限りではなく、それ以上のビット幅を用いてもよい。
　図９４は、イメージセンサ１２１１が完全性演算値を送信する完全性演算値処理の第３の処理例を説明するフローチャートである。
　ステップＳ７０１において、セキュリティ部１３１０は、セッション鍵を導出する。
　ステップＳ７０２において、メッセージカウンタ１３０８は、フレームカウント値を初期化して１に設定する。
　ステップＳ７０３において、拡張モード対応CSI-2送信回路１３０４は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ７０４に進む。
　ステップＳ７０４において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信するか否かを判定する。
　ステップＳ７０４において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信しないと判定した場合、処理はステップＳ７０３に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ７０４において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信すると判定した場合、処理はステップＳ７０５に進む。
　ステップＳ７０５において、セキュリティ部１３１０は、フレームカウント値を用いて行われる完全性演算値の演算を準備する。
　ステップＳ７０６において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信する。
　ステップＳ７０７において、拡張モード対応CSI-2送信回路１３０４は、フレーム内のフレームエンド以外の送信が完了したか否かを判定する。ステップＳ７０７において、拡張モード対応CSI-2送信回路１３０４が、フレーム内のフレームエンド以外の送信が完了していないと判定した場合、処理はステップＳ７０３に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ７０７において、拡張モード対応CSI-2送信回路１３０４が、フレーム内のフレームエンド以外の送信が完了したと判定した場合、処理はステップＳ７０８に進む。
　ステップＳ７０８において、セキュリティ部１３１０は、フレームカウント値を用いて行われる完全性演算値の演算を完了する。
　ステップＳ７０９において、拡張モード対応CSI-2送信回路１３０４は、フレームエンドとともに完全性演算値を送信する。
　ステップＳ７１０において、メッセージカウンタ１３０８は、フレームカウント値が規定値までカウントされたか否かを判定する。ステップＳ７１０において、メッセージカウンタ１３０８が、フレームカウント値が規定値までカウントされていないと判定した場合、処理はステップＳ７１１に進む。
　ステップＳ７１１において、メッセージカウンタ１３０８は、フレームカウント値をインクリメントする。その後、処理はステップＳ７０３に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７１０において、メッセージカウンタ１３０８が、フレームカウント値が規定値までカウントされたと判定した場合、処理はステップＳ７１２に進む。ステップＳ７１２において、セキュリティ部１３１０は、セッション鍵を更新した後、処理はステップＳ７０２に戻り、以下、同様の処理が繰り返して行われる。
　そして、ステップＳ７０３において、拡張モード対応CSI-2送信回路１３０４が、セッションを終了すると判定した場合、処理はステップＳ７１３に進む。
　ステップＳ７１３において、セキュリティ部１３１０は、セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　このように、イメージセンサ１２１１は、画像フレームごとの完全性演算値を演算して一括送信してもよい。その場合の完全性演算値は、画像データ以降の埋込データ内またはユーザ定義データ内または読み出し応答内に格納されて送信される。
　フレームスタートまたはフレームエンドは、例えば、16ビットのフレーム番号を含んでもよい。このフレーム番号は、所定のフレームに対応するフレームスタートとフレームエンドとで同一であってもよい。16ビットのフレーム番号を使用する場合、フレーム番号が機能せず、ゼロに設定されたままのユースケースと区別するために、非ゼロであることが望ましいが、その限りではない。
　フレーム番号は、同じ仮想チャネルを持つフレームスタートパケットごとに１または２ずつインクリメントし、定期的に１へリセットされる。例えば、破損のために画像フレームがマスクされている（つまり、送信されてない）場合、フレーム番号は２ずつ増えてもよい。
　このような場合に対応するために、必要に応じて、フレーム番号のシーケンス内で１または２のインクリメントを自由に混在させてもよい。つまり、１ずつインクリメントされる場合、216-1回でフレーム番号は一周する。また、フレームレートが60fpsである場合、(216-1)÷60≒18分でフレーム番号が一周する。
　例えば、イメージセンサ１２１１が、同じセッション鍵で同じ初期化ベクトル値を用いてメッセージのGalois Message Authentication Code（GMAC）値などのMAC値を演算してメッセージおよびMAC値を送信する場合、攻撃者はメッセージおよびMAC値の連立方程式を計算することによってセッション鍵を簡単に入手できる。その場合、攻撃者は、MAC値を自由に改竄できるようになるため、メッセージの成りすまし、改竄、リプレイなどの攻撃が可能になる。
　そのため、フレーム番号を初期化ベクトル、つまりナンス値として用いる場合、フレーム番号が一周するまでにセッション鍵を更新する必要がある。例えば、フレームブランキングまたはラインブランキングの期間を活用することによって、ナンス値が一周（ロールオーバー）するまでにセッション鍵が更新されればよい。
　図９５は、イメージセンサ１２１１が完全性演算値を送信する完全性演算値処理の第４の処理例を説明するフローチャートである。
　ステップＳ７２１において、セキュリティ部１３１０は、セッション鍵を導出する。
　ステップＳ７２２において、メッセージカウンタ１３０８は、フレームカウント値の上位カウント値を初期化して０に設定する。
　ステップＳ７２３において、メッセージカウンタ１３０８は、フレームカウント値の下位カウント値を初期化して１に設定する。
　ステップＳ７２４において、拡張モード対応CSI-2送信回路１３０４は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ７２５に進む。
　ステップＳ７２５において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信するか否かを判定する。
　ステップＳ７２５において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信しないと判定した場合、処理はステップＳ７２４に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ７２５において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信すると判定した場合、処理はステップＳ７２６に進む。
　ステップＳ７２６において、セキュリティ部１３１０は、フレームカウント値の上位カウント値および下位カウント値を用いて行われる完全性演算値の演算を準備する。
　ステップＳ７２７において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信する。
　ステップＳ７２８において、拡張モード対応CSI-2送信回路１３０４は、フレーム内のフレームエンド以外の送信が完了したか否かを判定する。ステップＳ７２８において、拡張モード対応CSI-2送信回路１３０４が、フレーム内のフレームエンド以外の送信が完了していないと判定した場合、処理はステップＳ７２４に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ７２８において、拡張モード対応CSI-2送信回路１３０４が、フレーム内のフレームエンド以外の送信が完了したと判定した場合、処理はステップＳ７２９に進む。
　ステップＳ７２９において、セキュリティ部１３１０は、フレームカウント値の上位カウント値および下位カウント値を用いて行われる完全性演算値の演算を完了する。
　ステップＳ７３０において、拡張モード対応CSI-2送信回路１３０４は、フレームエンドとともに完全性演算値を送信する。
　ステップＳ７３１において、メッセージカウンタ１３０８は、フレームカウント値の下位カウント値が規定値までカウントされたか否かを判定する。ステップＳ７３１において、メッセージカウンタ１３０８が、フレームカウント値の下位カウント値が規定値までカウントされていないと判定した場合、処理はステップＳ７３２に進む。
　ステップＳ７３２において、メッセージカウンタ１３０８は、フレームカウント値の下位カウント値をインクリメントする。その後、処理はステップＳ７２４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７３１において、メッセージカウンタ１３０８が、フレームカウント値の下位カウント値が規定値までカウントされたと判定した場合、処理はステップＳ７３３に進む。ステップＳ７３３において、セキュリティ部１３１０は、フレームカウント値の上位カウント値をインクリメントした後、処理はステップＳ７２３に戻り、以下、同様の処理が繰り返して行われる。
　そして、ステップＳ７２４において、拡張モード対応CSI-2送信回路１３０４が、セッションを終了すると判定した場合、処理はステップＳ７３４に進む。
　ステップＳ７３４において、セキュリティ部１３１０は、セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　このように、フレーム番号を初期化ベクトルの一部、つまりナンス値の一部（例えば、下位カウント値）として用いる場合、ナンス値の残り（例えば、上位カウント値）も併用することによって、セッション鍵の更新を不要にすること、または、セッション鍵の更新頻度を減らすことができる。
　例えば、1ずつインクリメントで60fpsである場合、ナンス値が一周するのは、
　・4ビット幅の上位カウント値を併用すると24×(216-1)÷60≒5時間
　・8ビット幅の上位カウント値を併用すると28×(216-1)÷60≒78時間
　・12ビット幅の上位カウント値を併用すると212×(216-1)÷60≒52日
　・16ビット幅の上位カウント値を併用すると216×(216-1)÷60≒828日
　・20ビット幅の上位カウント値を併用すると220×(216-1)÷60≒36年
　・24ビット幅の上位カウント値を併用すると224×(216-1)÷60≒581年となる。
　ここで、イメージセンサ１２１１またはアプリケーションプロセッサ１２１２の電源が再起動（OFFの後にON）される場合、保護された画像データを再び送信する前に鍵交換が必要になるので、それに応じてセッション鍵は更新される。例えば、一般的な車載用途で、３日以上も電源を再起動しない可能性は低く、２年以上も電源を再起動しない可能性は極めて低いので、上位カウント値は8～6ビット幅あれば十分である。もちろん、その限りではなく、それ以上のビット幅を用いてもよい。
　例えば、給油式の車両であれば給油の際に電源OFFとすればよく、給油式または充電式の車両であっても車両点検の際に電源OFFとすれば、保護された画像データを再び送信する前に鍵交換が必要になるので、それに応じてセッション鍵は更新される。例えば、IoT（Internet of ThingsまたはIntelligence of Things）向けイメージセンサが想定される場合、電源が再起動されないことも想定されるので、上位カウント値は20～4ビット幅あれば十分である。もちろん、その限りではなく、それ以上のビット幅を用いてもよい。
　＜暗号化および復号＞
　図９６乃至図１００を参照して、暗号化および復号について説明する。
　図９６には、初期化ベクトルが格納される初期カウンタブロックの一例が示されている。
　図９６に示すように、初期化ベクトルの構造を共通化する一方で、バーチャルチャネル間で異なる値とすることで、より簡単な実装を可能とすることができる。また、CSI-2のバーチャルチャネル間で、共通のセッション鍵またはカウント値が用いられる。
　128ビットの初期カウンタブロックが、AES（Advanced Encryption Standard）-GCM（Galois/Counter Mode）またはAES-GMAC（Galois Message Authentication Code）によって暗号化に用いられたり、メッセージ認証に用いられたりする。
　例えば、初期カウンタブロックの暗号化には、図９７に示すようなGHASH関数や、図９８に示すようなGCTR関数などを利用することができる。
　初期化ベクトルは、図９９に示すような認証付き暗号化機能を有するGCM-AE（Authenticated Encryption）関数を利用した暗号化や、図１００に示すような認証付き復号機能を有するGCM-AD（Authenticated Decryption）関数を利用した復号に利用される。ただし、暗号化（復号）またはメッセージ認証の何れか一方の機能に限定利用されてもよい。
　例えば、初期化ベクトルIV、平文P、および追加認証データAをGCM-AE関数に入力すると平文Pの暗号化が行われ、その結果、暗号化テキストCおよび認証タグTが出力される。
　一方、初期化ベクトルIV、暗号化テキストC、追加認証データA、および認証タグTをGCM-AD関数に入力すると、暗号化テキストCの復号が行われて平文Pが出力され、認証タグTと認証タグT’が一致しなかった場合には、認証に失敗したことを示す結果（FAIL）が出力される。
　＜完全性演算値の第１の送信方式＞
　図１０１乃至図１０５を参照して、完全性演算値MACの第１の送信方式について説明する。
　図１０１には、ラインごとに完全性演算値MACを送信する画像データのデータ構造が示されている。このように、ラインごとに完全性演算値MACを送信する送信方式を、以下適宜、ラインMAC方式と称する。
　図示するように、CSI-2のラインごと、CCIコマンドごと、または、CCIリターンごとに、完全性演算値MACが送信される。このように、これらの間で初期化ベクトルが同一の値である場合、より多くのセッション鍵が必要となる。
　例えば、同一の初期化ベクトルおよび同一のセッション鍵を使用すると、完全性演算値MACが改竄される原因になることが想定される。
　そこで、同一の初期化ベクトルについては、VC0コマンド、VC0リターン、VC1、およびVC2ごとに、それぞれ合計で４つのセッション鍵を使用することが提案される。
　一方、異なる初期化ベクトルについては、３つ以下のセッション鍵を使用することが提案される。
　第１のケースでは、アップリンク向けの第１のセッション鍵をVC0コマンドで使用し、ダウンリンク向けの第２のセッション鍵をVC0リターン、VC1、およびVC2で使用する。第２のケースでは、CCI向けの第１のセッション鍵をVC0で使用し、CSI-2向けの第２のセッション鍵をVC1およびVC2で使用する。第３のケースでは、全て向けの１つのセッション鍵をVC0、VC1、およびVC2で使用する。
　また、合計で２つのメッセージカウント値が使用される。CSI-2で共通のメッセージカウント値はVC1およびVC2の間で使用され、CCIで独立したメッセージカウント値はVC0で使用される。
　なお、CSI-2の仮想チャネル間で共通なメッセージカウンタが用いられる例が示されているが、CSI-2の仮想チャネル間で独立したメッセージカウンタが用いられてもよい。その場合、フローチャートの一部が削除されればよい。また、その場合、CSI-2の仮想チャネル間でメッセージカウンタが同期されていてもよいし、非同期であってもよい。例えば、実装効率の観点でメッセージカウンタは共通化が望ましい場合もあるし、安全性の観点でメッセージカウンタは独立化が望ましい場合もある。
　例えば、図１０２に示す構造の初期化ベクトルは、全てのバーチャルチャネル（CSI-2およびCCI）において共通とされる。そして、この初期化ベクトルの一部または全部は、図１０３に示すように、送信側から受信側へ送信される。なお、Reserved（Res）２ビットとして、規定値（例えば、02、12）を用いてもよい。また、Source IDまたはFinal Destination IDとして、事前交換された値を用いてもよい。また、受信側は、送信側から受信側へ送信された値ではなく、受信側で把握している値を初期化ベクトルの一部または全部として用いてもよい。また、初期化ベクトルの一部または全部が送信側から受信側へ送信される場合、初期化ベクトルの一部または全部は暗号化されないで（平文で）送信されることが望ましいが、その限りではない。
　図１０３では、追加メッセージカウント値が拡張パケットヘッダ外に格納されて送信される例が示されているが、追加メッセージカウント値およびメッセージカウント値が拡張パケットヘッダ外に格納されて送信されてもよい。その場合、メッセージカウント値は拡張パケットヘッダ内にも格納されて送信されてもよい。なお、追加メッセージカウント値は一部のみ用いられてもよい。例えば、初期化ベクトル内の追加メッセージカウント値が40ビットの場合、実際の追加メッセージカウント値は16ビットのカウンタであってもよく、そのカウント値が初期化ベクトル内の追加メッセージカウント値の一部（例えば、LSB側16ビット）内に格納され、初期化ベクトル内の追加メッセージカウント値の残り（例えば、MSB側24ビット）内は規定値（例えば、024、124）が格納されてもよい。また、初期化ベクトル内の追加メッセージカウント値は全て規定値（例えば、040、140）が格納されてもよい。
　また、イメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信されて設定される初期化ベクトルの一部または全部は、イメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信されないように構成され、事前合意またはレジスタ設定などに基づいて設定されてもよい。
　図１０４には、CSI-2またはCCIの拡張フォーマットの一例が示されている。
　例えば、必須の拡張パケットヘッダePH0の先頭ビット（ReservedおよびeVC）または準先頭ビット（eVC）が、初期化ベクトルとして使用される。そして、アプリケーションプロセッサ１２１２は、そのビットを受信した直後に、上述の図９８に示したGCTR関数の計算を開始することができる。つまり、送信側および受信側は、eVC値を送信または受信する前までにeVC以外の初期化ベクトル構成要素の値を確定できるように構成されてもよい。
　図１０５に示すフローチャートを参照して、イメージセンサ１２１１が、ラインごとに完全性演算値MACを送信するラインMAC方式の送信処理について説明する。
　ステップＳ７４１において、セキュリティ部１３１０は、共通セッション鍵を導出する
。
　ステップＳ７４２において、メッセージカウンタ１３０８は、メッセージカウント値の上位カウント値を初期化して０に設定する。
　ステップＳ７４３において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値を初期化して０に設定する。
　ステップＳ７４４において、拡張モード対応CSI-2送信回路１３０４は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ７４５に進む。
　ステップＳ７４５において、拡張モード対応CSI-2送信回路１３０４は、第１のバーチャルチャネルの拡張パケットを送信するか否かを判定する。
　ステップＳ７４５において、拡張モード対応CSI-2送信回路１３０４が、第１のバーチャルチャネルの拡張パケットを送信しないと判定した場合、処理はステップＳ７４４に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ７４５において、拡張モード対応CSI-2送信回路１３０４が、第１のバーチャルチャネルの拡張パケットを送信すると判定した場合、処理はステップＳ７４６に進む。
　ステップＳ７４６において、セキュリティ部１３１０は、ステップＳ７４１で導出した共通セッション鍵を用いて、第１のバーチャルチャネルの完全性演算値を演算する。
　ステップＳ７４７において、拡張モード対応CSI-2送信回路１３０４は、ステップＳ７４６で算出された完全性演算値を第１のバーチャルチャネルの拡張パケットに配置し、その第１のバーチャルチャネルの拡張パケットを送信する。
　ステップＳ７４８において、拡張モード対応CSI-2送信回路１３０４は、第２のバーチャルチャネルの拡張パケットを送信するか否かを判定し、第２のバーチャルチャネルの拡張パケットを送信と判定されるまで処理を待機する。そして、ステップＳ７４８において、拡張モード対応CSI-2送信回路１３０４が、第２のバーチャルチャネルの拡張パケットを送信すると判定した場合、処理はステップＳ７４９に進む。
　ステップＳ７４９において、セキュリティ部１３１０は、ステップＳ７４１で導出した共通セッション鍵を用いて、第２のバーチャルチャネルの完全性演算値を演算する。
　ステップＳ７５０において、拡張モード対応CSI-2送信回路１３０４は、ステップＳ７４９で算出された完全性演算値を第２のバーチャルチャネルの拡張パケットに配置し、その第２のバーチャルチャネルの拡張パケットを送信する。
　ステップＳ７５１において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値が最大値までカウントされたか否かを判定する。
　ステップＳ７５１において、メッセージカウンタ１３０８が、メッセージカウント値の下位カウント値が最大値までカウントされていないと判定した場合、処理はステップＳ７５２に進む。ステップＳ７５２において、メッセージカウンタ１３０８は、メッセージカウント値の下位カウント値をインクリメントした後、処理はステップＳ７４４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７５１において、メッセージカウンタ１３０８が、メッセージカウント値の下位カウント値が最大値までカウントされたと判定した場合、処理はステップＳ７５３に進む。ステップＳ７５３において、メッセージカウンタ１３０８は、メッセージカウント値の上位カウント値をインクリメントした後、処理はステップＳ７４３に戻り、以下、同様の処理が繰り返して行われる。
　そして、ステップＳ７４４において、拡張モード対応CSI-2送信回路１３０４が、セッションを終了すると判定した場合、処理はステップＳ７５４に進む。
　ステップＳ７５４において、セキュリティ部１３１０は、共通セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　このように、初期化ベクトル構成が拡張仮想チャネルeVCまたは仮想チャネルVCを含むことによって、複数種類のCSI-2仮想チャネル間で、セッション鍵やメッセージカウンタが共通化されることが可能になる。また、CSI-2とCCIとの間で、セッション鍵を共通化されることが可能になる。なお、CSI-2仮想チャネル間で実質的なライン数が異なる場合、例えば、ダミーデータによってライン数が統一化されることによって、メッセージカウンタを共通化されることが可能になる。
　図１０５で説明した処理は、メッセージカウント値を下位カウント値とし、追加メッセージカウント値を上位カウント値とする例であり、CSI-2仮想チャネルが２種類ある場合の一例である。
　一方、初期化ベクトル構成は、拡張データタイプeDTまたはデータタイプDTを含んでもよい。その場合は同様に、複数種類のデータタイプ間で、セッション鍵やメッセージカウンタが共通化されることが可能になる。
　なお、Reserved、拡張仮想チャネルeVC、および拡張データタイプeDTは、CSI-2/CCI extension format exampleの先頭ビットとして格納されるので、プロセッサはこれらの一部または全部が受信されれば直ちにGCTR演算の一部（CIPHK）の演算を開始できる。また、イメージセンサ１２１１とアプリケーションプロセッサ１２１２との間でフレーム構成が事前に合意されている場合、アプリケーションプロセッサ１２１２は、これらの受信を省略してGCTR演算の一部（CIPHK）の演算を開始できる。つまり、これらの初期化ベクトル構成は、演算時間の観点で有利である。
　なお、追加メッセージカウント値をイメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信することによって、アプリケーションプロセッサ１２１２は、この値を初期化ベクトルに用いることができる。これにより、アプリケーションプロセッサ１２１２は、実装効率の観点から追加メッセージカウンタを設けないように構成されてもよいし、安全性の観点から追加メッセージカウンタを設けるように構成されてもよい。また、アプリケーションプロセッサ１２１２が追加メッセージカウンタを設けるように構成される場合、イメージセンサ１２１１は追加メッセージカウント値を送信しないように構成されてもよい。即ち、初期化ベクトルに拡張仮想チャネルeVCが含まれる場合、追加メッセージカウント値の送信は必須要件でない。
　＜完全性演算値の第２の配置例＞
　図１０６乃至図１０９を参照して、完全性演算値MACの第２の配置例について説明する。
　図１０６には、フレームごとに完全性演算値MACが配置された画像データのデータ構造が示されている。このように、フレームごとに完全性演算値MACを送信する送信方式を、以下適宜、フレームMAC方式と称する。
　図示するように、フレームエンドの拡張パケットフッタ残りePF1に配置されている完全性演算値MACのみが有効になり、他の完全性演算値MACは無効とされる。また、完全性演算値MACは、フレームの最後の拡張パケットフッタePFを除く各ラインの拡張パケットヘッダePH、パケットデータ、および拡張パケットフッタePFから導出される。
　例えば、図１０７に示す構造の初期化ベクトルは、ラインMACおよびフレームMAC（CSI-2のみ）において共通とされる。そして、この初期化ベクトルは、図１０８に示すように、送信側から受信側へ送信される。
　図１０８では、追加フレーム番号が拡張パケットヘッダ外に格納されて送信される例が示されている。その他、追加フレーム番号およびフレーム番号が拡張パケットヘッダ外に格納されて送信されてもよい。その場合、フレーム番号はフレームスタート内にも格納されて送信されてもよい。なお、追加フレーム番号は一部のみ用いられてもよい。例えば、初期化ベクトル内の追加フレーム番号が24ビットの場合、実際の追加フレーム番号は16ビットのカウンタであってもよく、そのカウント値が初期化ベクトル内の追加フレーム番号の一部（例えば、LSB側16ビット）内に格納され、初期化ベクトル内の追加フレーム番号の残り（例えば、MSB側8ビット）内は規定値（例えば、08、18）が格納されてもよい。また、初期化ベクトル内の追加フレーム番号は全て規定値（例えば、024、124）が格納されてもよい。
　また、イメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信されて設定される初期化ベクトルの一部または全部は、イメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信されないように構成され、事前合意またはレジスタ設定などに基づいて設定されてもよい。
　図１０９に示すフローチャートを参照して、イメージセンサ１２１１が、フレームごとに完全性演算値MACを送信するフレームMAC方式の送信処理について説明する。
　ステップＳ７６１において、セキュリティ部１３１０は、セッション鍵を導出する。
　ステップＳ７６２において、メッセージカウンタ１３０８は、追加フレーム番号が用いられる上位カウント値を初期化して０に設定する。
　ステップＳ７６３において、メッセージカウンタ１３０８は、フレーム番号が用いられる下位カウント値を初期化して１に設定する。
　ステップＳ７６４において、拡張モード対応CSI-2送信回路１３０４は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ７６５に進む。
　ステップＳ７６５において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信するか否かを判定する。
　ステップＳ７６５において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信しないと判定した場合、処理はステップＳ７６４に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ７６５において、拡張モード対応CSI-2送信回路１３０４が、拡張パケットを送信すると判定した場合、処理はステップＳ７６６に進む。
　ステップＳ７６６において、拡張モード対応CSI-2送信回路１３０４は、拡張パケットを送信する。
　ステップＳ７６７において、メッセージカウンタ１３０８は、メッセージカウント値が最大値までカウントされたか否かを判定する。
　ステップＳ７６７において、メッセージカウンタ１３０８が、メッセージカウント値が最大値までカウントされたと判定した場合、処理はステップＳ７６８に進む。ステップＳ７６８において、メッセージカウンタ１３０８は、メッセージカウント値を初期化して０に設定する。
　一方、ステップＳ７６７において、メッセージカウンタ１３０８が、メッセージカウント値が最大値までカウントされていないと判定した場合、処理はステップＳ７６９に進む。ステップＳ７６９において、メッセージカウンタ１３０８は、メッセージカウント値をインクリメントする。
　ステップＳ７６８およびステップＳ７６９の処理後、処理はステップＳ７７０に進み、拡張モード対応CSI-2送信回路１３０４は、フレーム内の拡張パケットを全て送信完了したか否かを判定する。
　ステップＳ７７０において、拡張モード対応CSI-2送信回路１３０４が、フレーム内の拡張パケットを全て送信完了していないと判定した場合、処理はステップＳ７６４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７７０において、拡張モード対応CSI-2送信回路１３０４が、フレーム内の拡張パケットを全て送信完了したと判定した場合、処理はステップＳ７７１に進む。
　ステップＳ７７１において、メッセージカウンタ１３０８は、下位カウント値が規定値までカウントされたか否かを判定する。
　ステップＳ７７１において、メッセージカウンタ１３０８が、下位カウント値が規定値までカウントされていないと判定した場合、処理はステップＳ７７２に進む。ステップＳ７７２において、メッセージカウンタ１３０８は、下位カウント値をインクリメントした後、処理はステップＳ７６４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７７１において、メッセージカウンタ１３０８が、下位カウント値が規定値までカウントされたと判定した場合、処理はステップＳ７７３に進む。ステップＳ７７３において、メッセージカウンタ１３０８は、上位カウント値をインクリメントした後、処理はステップＳ７６３に戻り、以下、同様の処理が繰り返して行われる。
　そして、ステップＳ７６４において、拡張モード対応CSI-2送信回路１３０４が、セッションを終了すると判定した場合、処理はステップＳ７７４に進む。
　ステップＳ７７４において、セキュリティ部１３１０は、共通セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　以上のように、図１０９で説明した処理は、フレーム番号を下位カウント値とし、追加フレーム番号を上位カウント値とする例である。ただし、完全性演算値の演算および送信、仮想チャネル、セッション鍵更新などについては省略されているが、上述したフローチャートの何れかの一部または全部と組み合わせられてもよい。他にフローチャートについても同様である。
　なお、フレーム番号は１または２のインクリメントが混在する可能性あるため、下位カウント値が規定値（例えば、最大値または最大値－１）である場合に上位カウント値をインクリメントすることが望ましい。ただし、フレーム番号のインクリメントが１のみであるならば、下位カウント値が最大値である場合に上位カウント値がインクリメントされればよい。
　なお、フレーム番号をイメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信することによって、アプリケーションプロセッサ１２１２は、この値を初期化ベクトルに用いることができる。従って、アプリケーションプロセッサ１２１２は、実装効率の観点からフレームカウンタを設けないように構成されてもよいし、安全性の観点からフレームカウンタを設けるように構成されてもよい。また、アプリケーションプロセッサ１２１２がフレームカウンタを設けるように構成される場合、イメージセンサ１２１１はフレーム番号を送信しないように構成されてもよい。即ち、初期化ベクトルに拡張仮想チャネルeVCが含まれる場合、フレーム番号の送信は必須要件でない。
　また、追加フレーム番号をイメージセンサ１２１１からアプリケーションプロセッサ１２１２へ送信することによって、アプリケーションプロセッサ１２１２は、この値を初期化ベクトルに用いることができる。従って、アプリケーションプロセッサ１２１２は、実装効率の観点から追加フレームカウンタを設けないように構成されてもよいし、安全性の観点から追加フレームカウンタを設けるように構成されてもよい。また、アプリケーションプロセッサ１２１２が追加フレームカウンタを設けるように構成される場合、イメージセンサ１２１１は追加フレーム番号を送信しないように構成されてもよい。
　フレームMAC方式の場合、初期化ベクトル内のメッセージカウント値は、規定の値（例えば、016、116）が格納されてもよいし、特定の拡張パケット（例えば、フレームスタートまたはフレームエンド）のメッセージカウント値が格納されてもよい。一方、ラインMAC方式の場合、初期化ベクトル内のメッセージカウント値は、メッセージカウント値が格納される。
　＜完全性演算値MACの送信方式の選択＞
　図１１０および図１１１を参照して、完全性演算値MACの送信方式の選択について説明する。
　図１１０は、イメージセンサ１２１１が、完全性演算値MACの送信方式を選択する選択処理を説明するフローチャートである。
　ステップＳ７８１において、拡張モード対応CSI-2送信回路１３０４は、ラインMAC方式で完全性演算値MACを送信するか否かを判定する。
　ステップＳ７８１において、拡張モード対応CSI-2送信回路１３０４が、ラインMAC方式で完全性演算値MACを送信すると判定した場合、処理はステップＳ７８２に進む。ステップＳ７８２において、拡張モード対応CSI-2送信回路１３０４は、ラインMAC方式を選択する。
　一方、ステップＳ７８１において、拡張モード対応CSI-2送信回路１３０４が、ラインMAC方式で完全性演算値MACを送信しないと判定した場合、処理はステップＳ７８３に進む。
　ステップＳ７８３において、拡張モード対応CSI-2送信回路１３０４は、フレームMAC方式で完全性演算値MACを送信するか否かを判定する。
　ステップＳ７８３において、拡張モード対応CSI-2送信回路１３０４が、フレームMAC方式で完全性演算値MACを送信すると判定した場合、処理はステップＳ７８４に進む。ステップＳ７８４において、拡張モード対応CSI-2送信回路１３０４は、フレームMAC方式を選択する。
　一方、ステップＳ７８３において、拡張モード対応CSI-2送信回路１３０４が、フレームMAC方式で完全性演算値MACを送信しないと判定した場合、処理はステップＳ７８５に進む。ステップＳ７８５において、拡張モード対応CSI-2送信回路１３０４は、完全性演算値MACを送信しない非MAC方式を選択する。
　ステップＳ７８２、ステップＳ７８４、またはステップＳ７８５の処理後、処理はステップＳ７８６に進む。ステップＳ７８６において、拡張モード対応CSI-2送信回路１３０４は、ラインMAC方式、フレームMAC方式、または非MAC方式のいずれかを示すセキュリティMAC情報（図１１１参照）を送信した後、処理は終了される。ただし、図１１１には、２ビット割り当てのセキュリティMAC情報が示されているが、異なるビット数の割り当て（例えば、１ビット、８ビット）でもよい。また、リザーブド領域データ（Reserved forfuture use）には、MAC値を送信しないこと（例えば、No MAC）が割り当てられてもよい。
　以上のように、イメージセンサ１２１１は、ラインMAC方式でMAC値を送信する（ラインMAC方式を選択）のか、フレームMAC方式でMAC値を送信する（フレームMAC方式を選択）のか、MAC値を送信しない（非MAC方式を選択）のかを自由に選択することができる。または、イメージセンサ１２１１は、アプリケーションプロセッサ１２１２と事前合意の上で、いずれかを選択してもよい。例えば、イメージセンサ１２１１は、最初はラインMAC方式を選択し、所定条件を満たす場合に他方式（例えば、フレームMAC方式）へ切り替えてもよい。例えば、最初はフレームMAC方式を選択し、所定条件を満たす場合に他方式（例えば、ラインMAC方式）へ切り替えてもよい。例えば、最初は非MAC方式を選択し、所定条件を満たす場合に他方式（例えば、フレームMAC方式）へ切り替えてもよい。
　そして、ラインMAC方式を選択するのか、フレームMAC方式を選択するのか、非MAC方式を選択するのかは、例えば、拡張パケットヘッダ（例えば、ePH2）内のSecurity Descriptor内や、埋込データ内、ユーザ定義データ内、読み出し応答内などに格納されてイメージセンサ１２１１から送信される。アプリケーションプロセッサ１２１２は、その受信に応じて、完全性演算値MACの送信方式の切り替えに対応することができる。
　なお、初期化ベクトルの混乱を避けるために、完全性演算値MACの送信方式を切り替える際は、フレームエンド送信の開始以後からフレームスタート送信の完了以前までに、切り替え後の送信方式をイメージセンサから送信されることが望ましいが、その限りではない。
　なお、ラインMAC方式なのかフレームMAC方式なのかを識別できるセキュリティMAC情報が初期化ベクトル内に含まれてもよい。その場合は、ラインMAC方式とフレームMAC方式との間で初期化ベクトルが確実に重複しないため、完全性演算値MACの送信方式の切り替えが円滑化される。セキュリティMAC情報が無いと、例えば完全性演算値MACの送信方式の切り替えタイミングによっては、初期化ベクトルの重複を避けるために、メッセージカウンタ１３０８内に格納される値の指定が必要になる場合もあり得る。
　＜メッセージカウント値およびフレームカウント値について＞
　図１１２乃至図１１５を参照して、メッセージカウント値およびフレームカウント値について説明する。
　図１１２には、メッセージカウント値およびフレームカウント値がロールオーバーする周期の一例が示されている。
　図１１２のＡに示すように、60fpsかつ画素2160行の場合では、メッセージカウント値は、上位カウント値16bitおよび下位カウント値16bitとすることで、約９時間でロールオーバーする。同様に、上位カウント値20bitおよび下位カウント値16bitでは約６日で、上位カウント値24bitおよび下位カウント値16bitでは約９６日で、上位カウント値28bitおよび下位カウント値16bitでは約４年で、上位カウント値32bitおよび下位カウント値16bitでは約６９年でロールオーバーする。
　図１１２のＢに示すように、60fpsかつ１毎インクリメントの場合では、フレームカウント値は、上位カウント値4bitおよび下位カウント値16bitとすることで、約５時間でロールオーバーする。同様に、上位カウント値8bitおよび下位カウント値16bitでは約７８時間で、上位カウント値12bitおよび下位カウント値16bitでは約５２日で、上位カウント値16bitおよび下位カウント値16bitでは約８２８日で、上位カウント値20bitおよび下位カウント値16bitでは約３６年で、上位カウント値24bitおよび下位カウント値16bitでは約５８１年でロールオーバーする。
　図１１３のＡに示すように、初期化ベクトル構成は、乱数で構成されるソルトを含む構成としてもよい。ただし、例えば乱数が生成されない場合、ソルトは規定値（例えば、032、132）でもよい。
　図１１３のＢに示すように、初期化ベクトル構成は、メッセージカウント値を含まないで（フレームカウント値を含んで）構成されてもよい。また、Source IDまたはFinal destination IDを含んで構成されてもよい。なお、追加フレーム番号、フレーム番号、追加メッセージカウント値、およびメッセージカウント値を含んで構成されてもよい。
　図１１３のＣに示すように、初期化ベクトル構成は、SPDMセッションIDを含んでもよい。一方、ビット幅を節約できる、Source IDとFinal destination IDとのXOR結果を含んでもよい。
　図１１３のＤに示すように、SPDMセッションIDは、後述するReqSessionIDとRspSessionIDとで構成されてもよい。
　図１１３のＥに示すように、初期化ベクトル構成は、セキュリティプロトコル情報（例えば、SPDM/HDCP）、拡張データタイプ、またはデータタイプを含んでもよい。
　なお、図１３３に示された各要素の並び順は交換されてもよい。MSB側（上位カウント値）とLSB側（下位カウント値）とは交換されてもよい。一部の要素が他要素（例えば、ソルトやePH内パラメータ、上述した初期化ベクトル構成要素などの一部または全部）に置き換えられてもよい。
　図１１４は、アプリケーションプロセッサ１２１２が、メッセージカウント値を用いてデータ検証を行うデータ検証処理を説明するフローチャートである。
　ステップＳ７９１において、セキュリティ部１３２６は、セッション鍵を導出する。
　ステップＳ７９２において、データ検証部１３２５は、プロセッサメッセージカウント値を初期化して０に設定する。
　ステップＳ７９３において、データ検証部１３２５は、プロセッサ追加メッセージカウント値を初期化して０に設定する。
　ステップＳ７９４において、拡張モード対応CSI-2受信回路１３２２は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ７９５に進む。
　ステップＳ７９５において、データ検証部１３２５は、イメージセンサ１２１１から追加メッセージカウント値を受信したか否かを判定する。ステップＳ７９５において、データ検証部１３２５が、イメージセンサ１２１１から追加メッセージカウント値を受信したと判定した場合、処理はステップＳ７９６に進む。
　ステップＳ７９６において、データ検証部１３２５は、プロセッサ追加メッセージカウント値と、イメージセンサ１２１１の追加メッセージカウント値との双方が不一致であるか否かを判定する。
　ステップＳ７９６において、データ検証部１３２５が、プロセッサ追加メッセージカウント値と、イメージセンサ１２１１の追加メッセージカウント値との双方が不一致でない（一致している）と判定した場合、処理はステップＳ７９７に進む。一方、ステップＳ７９５において、データ検証部１３２５が、イメージセンサ１２１１から追加メッセージカウント値を受信していないと判定した場合も、処理はステップＳ７９７に進む。
　ステップＳ７９７において、データ検証部１３２５は、イメージセンサ１２１１からメッセージカウント値を受信したか否かを判定する。ステップＳ７９７において、データ検証部１３２５が、イメージセンサ１２１１からメッセージカウント値を受信したと判定した場合、処理はステップＳ７９８に進む。
　ステップＳ７９８において、データ検証部１３２５は、プロセッサメッセージカウント値と、イメージセンサ１２１１のメッセージカウント値との双方が不一致であるか否かを判定する。
　ステップＳ７９８において、データ検証部１３２５が、プロセッサメッセージカウント値と、イメージセンサ１２１１のメッセージカウント値との双方が不一致でない（一致している）と判定した場合、処理はステップＳ７９９に進む。
　ステップＳ７９９において、データ検証部１３２５は、プロセッサメッセージカウント値が最大値までカウントされたか否かを判定する。ステップＳ７９９において、データ検証部１３２５が、プロセッサメッセージカウント値が最大値までカウントされたと判定した場合、処理はステップＳ８００に進む。
　ステップＳ８００において、データ検証部１３２５は、プロセッサメッセージカウント値を初期化して０に設定する。
　ステップＳ８０１において、データ検証部１３２５は、プロセッサ追加メッセージカウント値が最大値までカウントされたか否かを判定する。ステップＳ８０１において、データ検証部１３２５が、プロセッサ追加メッセージカウント値が最大値までカウントされたと判定した場合、処理はステップＳ８０２に進む。
　ステップＳ８０２において、セキュリティ部１３２６は、セッション鍵を更新する。
　ステップＳ８０３において、データ検証部１３２５は、プロセッサ追加メッセージカウント値を初期化して０に設定する。その後、処理はステップＳ７９４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７９７において、データ検証部１３２５が、イメージセンサ１２１１からメッセージカウント値を受信していないと判定した場合、処理はステップＳ７９４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７９９において、データ検証部１３２５が、プロセッサメッセージカウント値が最大値までカウントされていないと判定した場合、処理はステップＳ８０４に進む。ステップＳ８０４において、データ検証部１３２５は、プロセッサメッセージカウント値をインクリメントし、その後、処理はステップＳ７９４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ８０１において、データ検証部１３２５が、プロセッサ追加メッセージカウント値が最大値までカウントされていないと判定した場合、処理はステップＳ８０５に進む。ステップＳ８０５において、データ検証部１３２５は、プロセッサ追加メッセージカウント値をインクリメントし、その後、処理はステップＳ７９４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ７９６において、データ検証部１３２５が、プロセッサ追加メッセージカウント値と、イメージセンサ１２１１の追加メッセージカウント値との双方が不一致であると判定した場合、処理はステップＳ８０６に進む。また、ステップＳ７９８において、データ検証部１３２５が、プロセッサメッセージカウント値と、イメージセンサ１２１１のメッセージカウント値との双方が不一致であると判定した場合も、処理はステップＳ８０６に進む。
　ステップＳ８０６において、データ検証部１３２５は、異常が発生したとして異常時処理を行い、処理はステップＳ８０７に進む。また、ステップＳ７９４において、拡張モード対応CSI-2受信回路１３２２が、セッションを終了すると判定した場合も、処理はステップＳ８０７に進む。
　ステップＳ８０７において、セキュリティ部１３２６は、セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　図１１５は、アプリケーションプロセッサ１２１２が、フレームカウント値および追加フレームカウント値を初期化ベクトルに反映する反映処理を説明する図である。
　ステップＳ８１１において、セキュリティ部１３２６は、セッション鍵を導出する。
　ステップＳ８１２において、データ検証部１３２５は、プロセッサフレームカウント値を初期化して１に設定する。
　ステップＳ８１３において、データ検証部１３２５は、プロセッサ追加フレームカウント値を初期化して０に設定する。
　ステップＳ８１４において、データ検証部１３２５は、イメージセンサ１２１１からフレームカウント値を受信したか否かを判定し、イメージセンサ１２１１からフレームカウント値を受信したと判定されるまで処理を待機する。そして、ステップＳ８１４において、データ検証部１３２５が、イメージセンサ１２１１からフレームカウント値を受信したと判定した場合、処理はステップＳ８１５に進む。
　ステップＳ８１５において、セキュリティ部１３２６は、フレームカウント値を初期化ベクトルへ反映する。
　ステップＳ８１６において、データ検証部１３２５は、イメージセンサ１２１１から追加フレームカウント値を受信したか否かを判定し、イメージセンサ１２１１から追加フレームカウント値を受信したと判定されるまで、処理を待機する。
　そして、ステップＳ８１６において、データ検証部１３２５が、イメージセンサ１２１１からフレーム追加カウント値を受信したと判定した場合、処理はステップＳ８１７に進む。
　ステップＳ８１７において、セキュリティ部１３２６は、追加フレームカウント値を初期化ベクトルへ反映する。
　ステップＳ８１８において、データ検証部１３２５は、フレームカウント値および追加フレームカウント値が規定値までカウントされたか否かを判定する。ステップＳ８１８において、データ検証部１３２５は、フレームカウント値および追加フレームカウント値が規定値までカウントされたと判定した場合、処理はステップＳ８１９に進む。
　ステップＳ８１９において、セキュリティ部１３２６は、セッション鍵を更新する。
　ステップＳ８１９の処理後、または、ステップＳ８１８において、データ検証部１３２５は、フレームカウント値および追加フレームカウント値が規定値までカウントされていないと判定した場合、処理はステップＳ８２０に進む。
　ステップＳ８２０において、拡張モード対応CSI-2受信回路１３２２は、セッションを終了するか否かを判定し、セッションを終了しないと判定された場合、処理はステップＳ８１４に戻り、以下、同様の処理が繰り返して行われる。
　一方、ステップＳ８２０において、拡張モード対応CSI-2受信回路１３２２が、セッションを終了すると判定した場合、処理はステップＳ８２１に進む。
　ステップＳ８２１において、セキュリティ部１３２６は、セッション鍵を破棄またはクリーンアップし、その後、処理は終了される。
　なお、メッセージカウント値は１ずつインクリメントされるが、フレームカウント値（フレーム番号）のインクリメントは、シーケンス内で１または２のインクリメントが自由に混在する可能性がある。そのため、フレームカウント値および追加フレームカウント値は、イメージセンサから送信された値を優先して使用されることが望ましい。
　一方、メッセージカウント値および追加メッセージカウント値は、復号演算が迅速に開始されるために、イメージセンサ１２１１から送信された値よりもアプリケーションプロセッサ１２１２がカウントした値が優先して使用されてもよい。なお、図１１４および図１１５のフローチャートを参照して説明した処理は、セッション鍵を更新しないように構成されてもよい。
　略語はそれぞれ、eP：extended Packet、eVC：extended Virtual Channel、eDT：extended Data Type、である。AES-GCM/GMAC向けの初期化ベクトル例を示したが、本技術は、AES以外のブロック暗号（例えば、DES：Data Encryption Standard、トリプルDES）向けや、GCM/GMAC以外のアルゴリズム（例えば、CCM：Counter with Cipher block chaining-MAC）向けや、異なる鍵長（例えば、128 bits以外）向けや、異なるIV長（例えば、96 bits以外）向けに、必要に応じて構成要素や並び順や数値などが調整された上で適用されてもよい。
　一般に公開されているDMTF（Distributed Management Task Force）によるSPDM仕様内のKEY_EXCHANGE request message内のRandomDataまたはOpaqueData、Successful KEY_EXCHANGE_RSP response message内のRandomData、PSK_EXCHANGE request message内のRequesterContextまたはOpaquePSKData、PSK_EXCHANGE_RSP message内のResponderContextの一部または全部がソルトとして用いられてもよい。
　一方、セッションIDは、例えば、PSK_EXCHANGE_RSP message内またはKEY_EXCHANGE_RSPresponse message内のParam2内に1Byteで格納されて、SPDMレスポンダ（例えば、イメージセンサ）からSPDMリクエスタへ送信される。なお、PSK_EXCHANGE_RSP messageとKEY_EXCHANGE_RSP response messageとはSPDMオプションであるが、SPDMセッション鍵を導出するためには共通鍵暗号方式に対応するPSK_EXCHANGE_RSP messageまたは公開鍵暗号方式に対応するKEY_EXCHANGE_RSP response messageが実質的に必須であり、そのセッションIDが初期化ベクトル内に含まれてもよい。ただし、セッションIDは、同じエンドポイントに対する以前の５つのセッションまたはアクティブなセッションとは異なることが望ましい。
　また、PSK_EXCHANGE request messageまたはKEY_EXCHANGE request messageがリクエスタ側セッションIDとしてReqSessionID（例えば、２バイト）を含み、PSK_EXCHANGE_RSP response messageまたはSuccessful KEY_EXCHANGE_RSP response messageがレスポンダ側セッションIDとしてRspSessionID（例えば、２バイト）を含み、これら２つを連結した（例えば、４バイトの）session ID = Concatenate (ReqSessionID, RspSessionID) がリクエスタとレスポンダとの間のユニークなセッションIDとして用いられてもよい。その場合、複数種類のセッション間で、セッション鍵またはメッセージカウンタが共通化されることが可能になる。
　一方、ディスプレイ用途（例えば、DSI-2）では、SPDMでなくHDCP（High-bandwidth Digital Content Protection）がセキュリティプロトコルとして用いられてもよいため、SPDMなのかHDCPなのかを識別できるセキュリティプロトコル情報（図１１６参照）が初期化ベクトル内に含まれてもよい。ただし、図１１６には、２ビット割り当てのセキュリティプロトコル情報が示されているが、異なるビット数の割り当て（例えば、１ビット、８ビット）でもよい。また、リザーブド領域データ（Reserved for future use）には、セキュリティプロトコルに対応しないこと（例えば、No security protocol）が割り当てられてもよい。
　例えば、新たなフォーマット内、ePHフォーマット（例えば、Reserved、eVC、eDT、Security Descriptor）内またはセッションID内などの何れかに、SPDM専用またはHDCP専用のビットが割り当てられて定義され、それが初期化ベクトル内に含まれてもよい。その場合、複数種類のセキュリティプロトコル間で、セッション鍵またはメッセージカウンタが共通化されることが可能になる。同様に、拡張パケットヘッダ内の一部が初期化ベクトル内に含まれてもよく、例えば、Security Descriptor（例えば、Service Descriptorと称されてもよい）が初期化ベクトル内に含まれてもよい。その場合、異なるSecurity Descriptor間で、セッション鍵またはメッセージカウンタが共通化されることが可能になる。
　イメージセンサ１２１１またはアプリケーションプロセッサ１２１２は、図１１７に示すようなSource IDまたはFinal Destination IDとして、事前交換ではなく、拡張パケットヘッダ（例えば、ePH4）内に格納されて受信された値を用いてもよい。
　なお、３つ以上の機器（例えば、複数のカメラ、複数のディスプレイ）をケーブルで繋いで通信する接続形態として、前の機器に次の機器を「数珠繋ぎ」に連結するデイジーチェーン方式があり、Source ID（ソースID）およびFinal Destination ID（最終目的地ID）が初期化ベクトル内に含まれることによって、複数の機器間で、セッション鍵またはメッセージカウンタが共通化されることが可能になる。
　ただし、Source IDとFinal Destination IDとは、例えば、イメージセンサへのコマンドなのか、イメージセンサからのデータなのか、によって入れ替わる。これを避けるために、初期化ベクトル内のSource IDおよびFinal Destination IDを、例えば、Host IDおよびDevice IDと定義してもよい。ただし、例えばイメージセンサはホストにもデバイス（非ホスト）にもなり得るので、Source IDおよびFinal Destination IDと定義した方が望ましい場合もある。
　そのため、例えば、Source IDおよびFinal destination IDを論理演算（例えば、XOR）したIDが用いられてもよい。その場合、初期化ベクトル内に定義されるビット幅が節約される効果もある。なお、Source IDまたはFinal Destination IDは、I2CまたはI3Cの場合、上述した図１１７に示したようにMaster addressまたはSlave addressが格納されてもよい。
　なお、例えば、上述した図８６のデータ構造でイメージセンサ１２１１からアプリケーションプロセッサ１２１２へ画像データを送信する場合、E2E protectionを実現するために、イメージセンサ１２１１のデバイスIDがSource IDとして、アプリケーションプロセッサ１２１２のデバイスIDがFinal Destination IDとして格納される。
　一方、例えば、上述した図８６のデータ構造でアプリケーションプロセッサ１２１２からイメージセンサ１２１１へコマンド命令を送信する場合、E2E protectionを実現するために、アプリケーションプロセッサ１２１２のデバイスIDがSource IDとして、イメージセンサ１２１１のデバイスIDがFinal Destination IDとして格納される。その場合、図２に示したようなSerDes装置２５またはSerDes装置２６のデバイスIDは、中間的なDestination IDであり、Final Destination IDと区別されることが望ましい場合もある。ただし、場合によっては、IVフォーマットのFinal Destination IDは、Destination IDと置き換えられてもよい。また、eVCをVCと置き換えられてもよく、eDTをDTと置き換えられてもよい。
　また、eVCまたはVCは、Video stream、Audio stream、Camera stream、またはDisplayStreamなどの何れかのID（Stream ID）であってもよい。また、Video streamでなくAudiostreamがストリームとして用いられてもよいため、Video streamなのかAudio streamなのかを識別できるストリーム情報が初期化ベクトル内に含まれてもよい。その場合、Video streamとAudio streamとの間で、セッション鍵またはメッセージカウンタが共通化されることが可能になる。
　ナンス値の一部または全部は、異なるバーチャルチャネルのデータ内（例えば、フレームスタート内、埋込データ内、画像データ内、フレームエンド内）へ格納されて送信されてもよい。これは、例えば、特定のバーチャルチャネルのデータ内へナンス値の一部または全部を格納する余地がない場合に有効である。
　一方、ナンス値の一部または全部は、画像データ送信のバーチャルチャネルとは異なるバーチャルチャネルの、パケットデータ（Generic Short Packet Data Types、Generic Long Packet Data Types）またはユーザ定義データ（User Defined Byte-based Data）またはリザーブド領域データ（Reserved for future use）の少なくとも一部内へ格納されて送信されてもよい。つまり、それらは非画像データ内に格納されてもよい。
　なお、以上の説明では、撮像開始を明記しているが、撮像終了について明記してない。これは撮像方式がグローバルシャッタ方式なのかローリングシャッタ方式なのか等によって異なるためである。例えば、グローバルシャッタ方式であれば、全画素を一斉に撮像できるので、次処理の前までに撮像終了してもよいし、フレーム内の最初の画像データを送信する前までに撮像終了してもよい。一方、ローリングシャッタ方式であれば、画素の各行で実行される撮像および高速データ送信の少なくとも一部が重複して実行（並列実行）されてもよいため、フレーム内の最後の画像データを送信する前までに撮像終了すればよい。また、撮像開始の位置は一例であり、フレーム内の最初の画像データを送信する前の位置まで遅らせて実行されてもよい。
　＜異常の有無を検出し、検出結果に応じたメッセージを、特異メッセージとしてアプリケーションプロセッサに送信するイメージセンサの詳細な構成例＞
　車両に搭載され、複数の基板が積層された構造の撮像素子における故障を検出できるようにする撮像装置において、第２の基板に設けられた行駆動部が、第１の基板に設けられた画素アレイの画素信号の蓄積および読み出しを制御する制御信号を出力するタイミングと、行駆動部より出力された制御信号が、画素アレイを通過して、検出されるタイミングとが一致するか否かにより、故障を検出する技術が開示されている（国際公開第２０１７／２０９２２１号参照）。
　しかしながら、運転支援処理中や自動運転処理中の場合、センサの異常は、死傷事故へと直結する状態を引き起こすので、上述した故障検出によりセンサの異常が検出されるときには、一刻も早くセンサから車両へと警告する必要がある。また、上述した故障検出が実行される場合、センサの異常が検出されたときに、センサが突然画像データのストリームを停止すると、タイミングによっては運転中に画像データが途絶えてしまうので、運転支援処理や自動運転処理が中断することになるので、危険を誘発させる恐れがある。
　一方、より精度の良い異常検出用の信号を出力可能な固体撮像装置を提供するために、アナログ信号である画素信号を出力する画素と、画素信号をデジタル信号に変換してデジタル画素信号を生成する読み出し部と、デジタル画素信号を記憶する記憶部と、第１検査信号を記憶部に出力して、記憶部に記憶させる第１検査信号出力部とを有し、記憶部に記憶された第１検査信号は、あるフレームのデジタル画素信号の出力が終了した後、かつ、次のフレームのデジタル画素信号の出力を開始する前の期間に記憶部から出力されることを特徴とする技術が開示されている（特開２０１８－１２１３２５号公報参照）。
　このような技術を適用した場合、撮像装置外の画像処理部が第１検査信号と期待値との一致判定をすることになるが、一致判定に時間を要する。また、画像処理部の判定結果は撮像装置には分からない。加えて、第１検査信号は、ノイズ、干渉、および攻撃者による攻撃の少なくともいずれかによって改竄される可能性があり、正常であるにも拘わらず異常があると判定されたり、異常であるにも拘わらず正常であると判定されたりする可能性があった。
　すなわち、いずれにおいても、走行、歩行、および飛行などの推進が可能な車両、ロボット、ドローンなどの推進を制御する推進装置おいて、センサの異常に対して適切な対応ができず、安全性が低下する恐れがあった。
　そこで、イメージセンサ１２１１が、異常の有無を検出し、検出結果に応じたメッセージを、特異メッセージとして、画像データを送信する高速データ通信により、アプリケーションプロセッサ１２１２に送信するようにしてもよい。
　このような構成により、イメージセンサ１２１１の異常の有無に係るメッセージである特異メッセージをアプリケーションプロセッサ１２１２に対して迅速に通知させることが可能となる。
　結果として、アプリケーションプロセッサ１２１２においては、イメージセンサ１２１１の異常に対して、迅速に、かつ、適切な対応を実現することが可能となり、より安全性を高めることが可能となる。
　ここで、図１１８を参照して、異常の有無を検出し、検出結果に応じたメッセージを、特異メッセージとしてアプリケーションプロセッサに送信するイメージセンサ１２１１の詳細な構成例について説明する。図１１８は、異常の有無を検出し、検出結果に応じたメッセージを、特異メッセージとしてアプリケーションプロセッサに送信するイメージセンサ１２１１の詳細な構成例を示すブロック図である。
　図１１８のイメージセンサ１２１１は、画素１５０１、AD変換器１５０２、画像処理部１５０３、拡張モード対応CSI-2送信回路１５０４、物理層処理部１５０５、I2C/I3Cスレーブ１５０６、記憶部１５０７、妨害検出部１５０８、障害検出部１５０９、セキュリティ部１５１０、侵害検出部１５１１、および温度検出部１５１２を備えて構成される。
　なお、画素１５０１、AD変換器１５０２、画像処理部１５０３、拡張モード対応CSI-2送信回路１５０４、物理層処理部１５０５、I2C/I3Cスレーブ１５０６、および記憶部１５０７は、他の実施の形態において対応する画素１３０１、AD変換器１３０２、画像処理部１３０３、拡張モード対応CSI-2送信回路１３０４、物理層処理部１３０５、I2C/I3Cスレーブ１３０６、および記憶部１３０７と同様の機能を備えた構成であるので、その詳細な説明は省略する。
　妨害検出部１５０８は、画素１５０１、AD変換器１５０２、および画像処理部１５０３の少なくともいずれかと電気的に直接的に、または、間接的に接続されている。尚、図１１９においては、妨害検出部１５０８は、画素１５０１、AD変換器１５０２、および画像処理部１５０３の全てと接続される例が示されているが、少なくともそのいずれかと接続されていればよい。
　妨害検出部１５０８は、画素１５０１において受光した光量に応じた光電変換により出力されるアナログ信号からなる画素信号、AD変換器１５０２によりデジタル信号に変換された画素信号、および、画像処理部１５０３より出力される画像処理された画像データの少なくともいずれかの出力結果に基づいて、イメージセンサ１２１１の画像を実質的に無効化または改竄する光照射攻撃（妨害）の有無から異常を検出し、検出結果に基づいた特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　このような構成により、アプリケーションプロセッサ１２１２は、高速データ通信により、妨害の有無に応じた特異メッセージを取得することで、特異メッセージに応じた迅速な対応が可能となる。
　障害検出部１５０９は、例えば、通信経路または物理層処理部１５０５に対して電気的に直接接続または間接接続される。
　障害検出部１５０９は、イメージセンサ１２１１に対して、例えば、電力注入、電磁照射（注入）、レーザ照射（注入）の何れかによって、イメージセンサ１２１１内の一部または全部の動作を無効化させる、誤動作させる、偽情報を流入させる、および情報を流出させる等の注入攻撃の有無を検出し、検出結果に基づいた特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　また、障害検出部１５０９は、イメージセンサ１２１１に悪影響を与えるハードウエアトロイ（つまり、異物）を挿入することで、イメージセンサ１２１１内の一部または全部の動作を無効化させる、誤動作させる、偽情報を流入させる、および情報を流出させる等の挿入攻撃の有無を検出し、検出結果に基づいた特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　このような構成により、アプリケーションプロセッサ１２１２は、高速データ通信により、障害の有無に応じた特異メッセージを取得することで、特異メッセージに応じた迅速な対応が可能となる。
　侵害検出部１５１１は、例えば、セキュリティ部１５１０に対して電気的に直接接続または間接接続され、セキュリティ部１５１０の異常を検出し、検出結果に基づいた特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　セキュリティ部１５１０は、例えば、イメージセンサ１２１１内の一部または全部の動作を無効化させたり、誤動作させたり、偽情報を流入させたり、情報を流出させる注入攻撃に加えて、イメージセンサ１２１１に用いられる電力またはイメージセンサ１２１１から生じる電磁を解析することでイメージセンサ１２１１内情報を流出させる解析攻撃（電力解析攻撃、電磁解析攻撃）を受ける可能性がある。
　そこで、侵害検出部１５１１は、注入攻撃に伴うセキュリティ部１５１０内の改竄の有無を論理的に検出する。侵害検出部１５１１は、電力解析または電磁解析に必要な攻撃物体（例えば、プローブ）がセキュリティ部１５１０の付近に存在するか否かを物理的に検出する。侵害検出部１５１１は、検出結果に基づいた特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　このような構成により、アプリケーションプロセッサ１２１２は、高速データ通信により、侵害の有無に応じた特異メッセージを取得することで、特異メッセージに応じた迅速な対応が可能となる。
　温度検出部１５１２は、イメージセンサ１２１１の温度を検出し、動作保証温度の上限値（第１閾値）より低く、かつ、下限値（第２閾値）よりも高い状態であるか否かに基づいて、特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　このような構成により、アプリケーションプロセッサ１２１２は、高速データ通信により、イメージセンサ１２１１が動作温度に応じた特異メッセージを受信することで、特異メッセージに応じた迅速な対応が可能になる。
　メッセージカウンタ１５１３は、基本的な機能において、メッセージカウンタ１３０８（図７６）と同様であるが、さらに、メッセージカウント値として、インクリメントまたはデクリメントする第１カウンタと、インクリメントまたはデクリメントする第２カウントとを用いる。メッセージカウンタ１５１３は、第１カウンタと第２カウンタとを用いることにより、メッセージカウント値に対する不具合や改竄に対する耐性を向上させる。尚、メッセージカウンタ１５１３の詳細については、図１５０乃至図１５２を参照して後述する。もちろん、メッセージカウンタ１５１３の代わりに、メッセージカウンタ１３０８（第１カウンタと第２カウントとのうちの何れか一方のみ）が用いられてもよい。
　＜妨害検出部による妨害検出（その１）＞
　イメージセンサ１２１１に対して、例えば、所定の強度よりも高い強度の可視光、赤外光、レーザ光などの何れかが照射されると、イメージセンサ１２１１により撮像される画像を実質的に無効化または改竄されることになる。
　このため、例えば、所定の強度よりも高い強度の可視光、赤外光、レーザ光などの何れかが検出されるような場合、光照射攻撃（妨害）に起因する異常が発生したものとみなすことができる。
　そこで、出力結果に基づいて、所定の強度よりも高い強度の可視光、赤外光、レーザ光などの何れかが検出されるような場合、妨害検出部１５０８は、異常が発生したことを示すメッセージを特異メッセージとして、画像データを送信する高速データ通信により、アプリケーションプロセッサ１２１２に通知する。
　これにより、イメージセンサ１２１１に異常が発生したことを示す特異メッセージが、画像データを送信する高速データ通信により通知されることになるので、アプリケーションプロセッサ１２１２は、特異メッセージに応じた迅速な対応が可能になる。
　より具体的には、無効化の妨害をイメージセンサ１２１１が受けた場合、所定範囲（有効画素領域の一部または全部）内の画素群それぞれのR、G、B、IRなどの少なくとも何れかの画素値は、飽和に近づくことになる。
　つまり、所定範囲内の画素群の画素値が第１閾値（上限値）以上になる。そこで、所定範囲内の画素群の画素値が第１閾値（上限値）以上になることが検出される場合、例えば、イメージセンサ１２１１の画素の画素値が飽和に近づいていることを示す異常メッセージが特異メッセージとしてアプリケーションプロセッサ１２１２に送信されるようにする。
　なお、光照射攻撃に限らず、広い範囲（所定範囲）の画素の画素値が飽和に近づいているような場合、広い範囲の画素に異常が発生していることを示す異常メッセージが特異メッセージとして送信されるようにしてもよい。このような特異メッセージの通知は、例えば、イメージセンサ１２１１に対して妨害光が偶発的に照射された場合でも有効である。
　一方、例えば、塗料、暗幕、煙幕、および遮蔽材などの少なくとも何れかによってイメージセンサ１２１１の表面（受光面）が遮蔽されて、イメージセンサ１２１１により撮像される画像を実質的に無効化する光遮蔽攻撃（妨害）もある。
　そこで、イメージセンサ１２１１の表面が遮蔽されたことが検出されるような場合、イメージセンサ１２１１からアプリケーションプロセッサ１２１２に対して異常を示すメッセージとして特異メッセージが通知されるようにする。
　これにより、特異メッセージを受信するアプリケーションプロセッサ１２１２は、特異メッセージに応じた迅速な対応が可能になる。
　より具体的には、遮蔽による無効化の妨害をイメージセンサ１２１１が受けた場合、所定範囲内の画素群それぞれのR、G、B、IRなどの少なくとも何れかの画素値は、第２閾値（下限値）に近づくことになる。
　すなわち、遮蔽による無効化の妨害をイメージセンサ１２１１が受けた場合、所定範囲内の画素群の画素値が第２閾値以下になり遮蔽されたことが検出される。そこで、遮蔽されたことが検出された場合、例えば、イメージセンサ１２１１は画素値が第２閾値に近づいている異常を示す異常メッセージを特異メッセージとして送信する。
　なお、光遮蔽攻撃に限らず、広い範囲（所定範囲）内の画素値が第２閾値（下限値）に近づいている場合、異常メッセージが送信されるようにしてもよい。このような特異メッセージの通知は、例えば、イメージセンサ１２１１の表面（受光面）が偶発的に遮蔽（妨害）された場合にも有効である。
　尚、妨害検出部１５０８の検出結果に基づいて、イメージセンサ１２１１の無効化の妨害を示す異常が検出されない場合、正常であることを示すメッセージが特異メッセージとして送信されるようにしてもよいし、特異メッセージが送信されないようにしてもよい。
　また、妨害検出部１５０８が用いる第１閾値（上限値）および第２閾値（下限値）は、例えば、記憶部１５０７に予め記憶させるようにしてもよい。この場合、妨害検出部１５０８は、記憶部１５０７に記憶された第１閾値（上限値）および第２閾値（下限値）を読み出して用いるようにしてもよい。また、第１閾値（上限値）および第２閾値（下限値）は、任意に設定できるようにしてもよい。
　（妨害検出部による妨害検出処理（その１））
　次に、図１１９のフローチャートを参照して、妨害検出部１５０８による妨害検出処理（その１）について説明する。
　ステップＳ１００１において、画素１５０１による撮像処理、AD変換器１５０２によるAD変換処理、および画像処理部１５０３による画像処理の少なくともいずれかの処理が実行され、処理結果が妨害検出部１５０８に出力される。
　ステップＳ１００２において、妨害検出部１５０８は、画素１５０１による撮像処理、AD変換器１５０２によるAD変換処理、および画像処理部１５０３による画像処理の少なくともいずれかの処理結果に基づいて、所定範囲内の画素群の画素値が第１閾値（上限値）以上である（上限値よりも大きい）か否かを判定する。
　ステップＳ１００２において、所定範囲内の画素群の画素値が第１閾値（上限値）以上であると判定された場合、処理は、ステップＳ１００３に進む。
　ステップＳ１００３において、妨害検出部１５０８は、所定範囲内の画素群の画素値が第１閾値（上限値）以上であり、所定の強度よりも高い強度の可視光、赤外光、レーザ光などの何れかが検出されており、光照射攻撃（妨害）に起因する異常が発生していることを示す第１異常メッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に送信する。
　また、ステップＳ１００２において、所定範囲内の画素群の画素値が第１閾値（上限値）以上ではないと判定された場合、処理は、ステップＳ１００４に進む。
　ステップＳ１００４において、妨害検出部１５０８は、画素１５０１による撮像処理、AD変換器１５０２によるAD変換処理、および画像処理部１５０３による画像処理の少なくともいずれかの処理結果に基づいて、所定範囲内の画素群の画素値が第２閾値（下限値）以下である（下限値よりも小さい）か否かを判定する。
　ステップＳ１００４において、所定範囲内の画素群の画素値が第２閾値（下限値）以下であると判定された場合、処理は、ステップＳ１００５に進む。
　ステップＳ１００５において、妨害検出部１５０８は、所定範囲内の画素群の画素値が第２閾値（下限値）以下であり、例えば、塗料、暗幕、煙幕、および遮蔽材などの少なくとも何れかによってイメージセンサ１２１１の表面（受光面）が遮蔽されて、イメージセンサ１２１１により撮像される画像を実質的に無効化する光遮蔽攻撃（妨害）に起因する異常が発生していることを示す第２異常メッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に送信する。
　さらに、ステップＳ１００４において、所定範囲内の画素群の画素値が第２閾値（下限値）以下ではないと判定された場合、処理は、ステップＳ１００６に進む。
　ステップＳ１００６において、妨害検出部１５０８は、イメージセンサ１２１１により撮像される画像を実質的に無効化する攻撃（妨害）に起因する異常が発生していないことを示す正常メッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に送信する。
　以上の処理により、イメージセンサ１２１１に対する攻撃（妨害）が発生するような場合、画像データを送信する高速データ通信により通知されることになるので、アプリケーションプロセッサ１２１２において、迅速、かつ適切な対応を実現することが可能となる。
　＜妨害検出部による妨害検出（その２）＞
　以上においては、イメージセンサ１２１１に対する、光の強度の変化による攻撃（妨害）の有無を検出して特異メッセージとして通知する例について説明してきた。
　イメージセンサ１２１１が、ToF（Time of Flight）法を用いた測距センサとして機能される際、光源より照射されるレーザ光の発光パターンに応じた受光パターンを検出することで自らが照射した光源の反射光として認識し、他の光源からの受光パターンと区別する。この際、測距センサは、自らの光源から照射した光の照射タイミングと受光タイミングとの差分に基づいた往復時間により画素単位で測距を実現し、測距結果から距離画像を生成する。
　ここで、距離画像とは、被写体の測距センサからの奥行き方向の距離を画素ごとに検出し、検出した距離に基づく距離画素信号からなる画像を指す。その場合に測距センサは、例えば、照明部、撮像部、制御部、表示部、記憶部を備えた構成として実現される。
　しかしながら、この発光パターン（受光パターン）が何らかの原因で改竄されると、自らの光源より照射された発光パターンを認識できないので、適切な測距を実現することができない状態となり、異常が発生した状態となる。
　そこで、妨害検出部１５０８は、記憶部１５０７に予め発光パターン（受光パターン）を格納パターンとして記憶しておき、実際にイメージセンサ１２１１により受光された受光パターンとの比較により異常の発生の有無を検出するようにしてもよい。
　照明部は、照明制御部とレーザ光源を備える。照明制御部は、制御部の制御に基づいてレーザ光源が照射光（レーザ光）を照射するパターンを制御する。例えば、照明制御部は制御部から供給される照射信号に含まれる照射コードに従ってレーザ光源が照射光を照射するパターン（発光パターン）を制御する。
　撮像部は、レンズ、撮像素子、および信号処理回路を備える。レンズは入射光を撮像素子の撮像面に結像させる。レンズの構成は任意であり、例えば、複数のレンズ群により構成されていてもよい。撮像素子は、例えば、ToF法を用いたCMOS（Complementary Metal Oxide Semiconductor）イメージセンサから成るイメージセンサ１２１１により実現される。撮像素子は、制御部の制御に基づいて被写体の撮像を行い、その結果得られた画像信号を信号処理回路に供給する。例えば、撮像素子は、制御部から供給される参照信号と、レーザ光源から照射された照射光が被写体により反射された反射光を含む受信光との相関を示す画素信号を生成し、信号処理回路に供給する。なお、参照信号は、受信光との相関の検出に用いるパターンを示す参照コードを含む。
　ここで、受光波形パターン、受光スポットパターン、受光ドットパターン、受光軌跡パターンなどの何れかの受光パターンについて、受信光からイメージセンサ１２１１が抽出した結果に異常がある場合、撮像素子（画素および変換器に相当）および信号処理回路（画像処理部に相当）を含んで構成される撮像部（イメージセンサ１２１１に相当）から制御部（アプリケーションプロセッサ１２１２に相当）に対して異常メッセージが送信されてもよい。
　一方、イメージセンサ１２１１内の記憶部内に格納パターンを格納しないで、特異メッセージとして受光パターンが送信されてもよい。その場合、イメージセンサ１２１１外の記憶部（例えば、アプリケーションプロセッサ１２１２）内に格納パターンが格納されることによって、受光パターンとの比較がなされて正常か異常かが判断される。
　＜受光パターンについて＞
　受光パターンそのものが送信される場合、受光してない画素に関連する情報が高速データ送信されないようにしてもよい。例えば、図１２０で示されるような白丸印で示される画素が受光される画素を示すドットパターンである場合、白丸印で示される受光されたドットパターンに関連する情報のみが高速データ送信されるようにしてもよい。例えば、受光してない画素は、受光スポットパターンや受光ドットパターンが正常か異常かを判断するために用いられる。その場合、イメージセンサ１２１１は、高速データ送信するデータ量を最小限に抑えつつ、受光パターンが正常か異常かを判断できる。
　また、周期的な受光ドットパターンであれば、記憶部内に格納される格納パターンの種類を減らすことが可能になる。例えば、図１２１で示されるような白丸印で示される第１の画素値で受光される画素と、斜線の丸印で示される第２の画素値で受光される画素と、が受光される画素を示すドットパターンである場合、奇数行のドットパターンと偶数行のドットパターンとの２行分のドットパターンが記憶部１５０７内に格納されれば、実際の受光パターンが正常か異常かを判断することが可能となる。このように、周期的な受光ドットパターンなどでは、繰り返し表される行数分のドットパターンだけを記憶部１５０７に記憶させるようにすることで、格納パターンが記憶されることになるので、記憶容量を削減することが可能となる。
　さらに、受光波形パターンについては、記憶部１５０７内に格納パターンが格納されることによって正常か異常かが判断されてもよいが、受光波形パターンは画像データや画像パターンとは無関係である。そのため、受光波形パターンで異常の有無を判断させるようにすることで、受光スポットパターン、受光ドットパターン、受光軌跡パターンなどの何れかのパターンが複雑であっても、記憶部１５０７の容量に対する影響を低減することが可能となる。
　（妨害検出部による妨害検出処理（その２））
　次に、図１２２のフローチャートを参照して、妨害検出部１５０８による受光パターンを用いた妨害検出処理（その２）について説明する。
　ステップＳ１０３１において、画素１５０１による撮像処理、AD変換器１５０２によるAD変換処理、および画像処理部１５０３による画像処理の少なくともいずれかの処理が実行され、処理結果が妨害検出部１５０８に出力される。
　ステップＳ１０３２において、妨害検出部１５０８は、画素１５０１による撮像処理、AD変換器１５０２によるAD変換処理、および画像処理部１５０３による画像処理の少なくともいずれかの処理結果に基づいて、受光パターンを抽出する。
　ステップＳ１０３３において、妨害検出部１５０８は、記憶部１５０７に予め記憶されている正常時の受光パターンである格納パターンを読み出して、受光パターンと比較する。
　ステップＳ１０３４において、妨害検出部１５０８は、受光パターンと格納パターンとの比較結果に基づいて、受光パターンと格納パターンとが一致しているか否かを判定する。
　ステップＳ１０３４において、受光パターンと格納パターンとが一致していると判定された場合、処理は、ステップＳ１０３５に進む。
　ステップＳ１０３５において、妨害検出部１５０８は、イメージセンサ１２１１により実現される測距センサには異常が発生していないものとみなし、異常が発生していないことを示す正常メッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に送信する。
　ステップＳ１０３４において、受光パターンと格納パターンとが一致していないと判定された場合、処理は、ステップＳ１０３６に進む。
　ステップＳ１０３６において、妨害検出部１５０８は、イメージセンサ１２１１により実現される測距センサには異常が発生しているものとみなし、異常が発生していることを示す異常メッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に送信する。
　以上の処理により、イメージセンサ１２１１により測距センサが実現されるような場合、受光パターンに異常が発生すると、対応する特異メッセージが画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知されることになる。結果として、アプリケーションプロセッサ１２１２は、イメージセンサ１２１１において発生した異常に対して、迅速かつ適切な対応を実現することが可能となる。
　＜障害検出部による障害検出＞
　次に、障害検出部１５０９による障害検出について説明する。
　イメージセンサ１２１１は、イメージセンサ１２１１内の一部または全部の動作を無効化させる、誤動作させる、偽情報を流入させる、および情報を流出させる等の注入攻撃を受けた場合、物理層の電圧状態またはクロック状態に異常な変化が生じる。
　そこで、障害検出部１５０９は、物理層の電圧状態の変化またはクロック状態の変化を検出する。
　障害検出部１５０９は、物理層の電圧状態の異常な変化を検出した場合、例えば、イメージセンサ１２１１において電力異常または電圧異常（例えば、電圧振幅、電圧極性、IRドロップ）などが生じていることを示す第１異常メッセージからなる特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　また、障害検出部１５０９は、物理層のクロック状態の異常な変化を検出した場合、クロック異常（例えば、クロックの周波数、周期性、回数、ジッタ）が生じていることを示す第２異常メッセージからなる特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　なお、障害検出部１５０９は、注入攻撃に限らず、偶発的なノイズまたは干渉などによって異常が生じる場合も、異常を示すメッセージを特異メッセージとして送信してもよい。
　さらに、例えば、特定条件を満たす場合に起動してイメージセンサ１２１１に対して悪影響を与えるハードウエアトロイ（つまり、異物）を挿入することで、イメージセンサ１２１１内の一部または全部の動作を無効化させたり、誤動作させたり、偽情報を流入させたり、情報を流出させる挿入攻撃がある。
　イメージセンサ１２１１が挿入攻撃を受ける場合、電気特性（例えば、インピーダンス値のZ値、抵抗値のR値、インダクタンス値のL値、キャパシタンス値のC値、品質係数のQ値）または伝送特性（例えば、データ伝送品質、挿入損失、反射損失）などに異常な変化が生じる。
　そこで、障害検出部１５０９は、電気特性を検出し、電気特性に異常な変化が検出される場合、例えば、イメージセンサ１２１１において電気特性の異常が生じていることを示す第３異常メッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　また、障害検出部１５０９は、伝送特性を検出し、伝送特性に異常な変化が検出される場合、例えば、イメージセンサ１２１１において伝送特性の異常が生じていることを示す第４異常メッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　なお、障害検出部１５０９は、通信経路または物理層処理部１５０５の開放または短絡、つまり断線または圧迫の有無やその可能性を検出するようにして、検出結果に応じて異常が生じている場合、異常が発生していることを示す特異メッセージを送信するようにしてもよい。
　また、障害検出部１５０９は、挿入攻撃に限らず、偶発的な破損、経年変化、および温度変化などの何れかによって異常が生じる場合も、異常を示すメッセージを特異メッセージとして送信するようにしてもよい。
　尚、障害検出部１５０９は、異常が検出されなかった場合、正常メッセージからなる特異メッセージを送信するようにしてもよいし、特異メッセージを送信しないようにしてもよい。
　（障害検出部による障害検出処理）
　次に、図１２３のフローチャートを参照して、障害検出部１５０９による障害検出処理について説明する。
　ステップＳ１０５１において、障害検出部１５０９は、物理層の電圧状態を検出する。
　ステップＳ１０５２において、障害検出部１５０９は、物理層の電圧状態が閾値範囲外であるか否か、すなわち、異常な変化が発生しているか否かを判定する。
　ステップＳ１０５２において、物理層の電圧状態が閾値範囲外であり、異常な変化が発生していると判定された場合、処理は、ステップＳ１０５３に進む。
　ステップＳ１０５３において、障害検出部１５０９は、イメージセンサ１２１１において電力異常または電圧異常（例えば、電圧振幅、電圧極性、IRドロップ）などが生じていることを示す第１異常メッセージからなる特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　また、ステップＳ１０５２において、物理層の電圧状態が閾値範囲外ではないと判定された場合、処理は、ステップＳ１０５４に進む。
　ステップＳ１０５４において、障害検出部１５０９は、物理層のクロック状態を検出する。
　ステップＳ１０５５において、障害検出部１５０９は、物理層のクロック状態が閾値範囲外であるか否か、すなわち、異常な変化が発生しているか否かを判定する。
　ステップＳ１０５５において、物理層のクロック状態が閾値範囲外であり、異常な変化が発生していると判定された場合、処理は、ステップＳ１０５６に進む。
　ステップＳ１０５６において、障害検出部１５０９は、クロック異常（例えば、クロックの周波数、周期性、回数、ジッタ）が生じていることを示す第２異常メッセージからなる特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　さらに、ステップＳ１０５５において、物理層のクロック状態が閾値範囲外ではないと判定された場合、処理は、ステップＳ１０５７に進む。
　ステップＳ１０５７において、障害検出部１５０９は、電気特性を検出する。
　ステップＳ１０５８において、障害検出部１５０９は、電気特性が閾値範囲外であるか否か、すなわち、異常な変化が発生しているか否かを判定する。
　ステップＳ１０５８において、電気特性が閾値範囲外であり、異常な変化が発生していると判定された場合、処理は、ステップＳ１０５９に進む。
　ステップＳ１０５９において、障害検出部１５０９は、イメージセンサ１２１１において電気特性の異常が生じていることを示す第３異常メッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　さらに、ステップＳ１０５８において、電気特性の異常な変化が発生していないと判定された場合、処理は、ステップＳ１０６０に進む。
　ステップＳ１０６０において、障害検出部１５０９は、伝送特性を検出する。
　ステップＳ１０６１において、障害検出部１５０９は、伝送特性が閾値範囲外であるか否か、すなわち、異常な変化が発生しているか否かを判定する。
　ステップＳ１０６１において、伝送特性が閾値範囲外であり、異常な変化が発生していると判定された場合、処理は、ステップＳ１０６２に進む。
　ステップＳ１０６２において、障害検出部１５０９は、イメージセンサ１２１１において伝送特性の異常が生じていることを示す第４異常メッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　さらに、ステップＳ１０６１において、伝送特性の異常な変化が発生していないと判定された場合、処理は、ステップＳ１０６３に進む。
　ステップＳ１０６３において、障害検出部１５０９は、イメージセンサ１２１１が正常であることを示すメッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　以上の処理により、注入攻撃や挿入攻撃の有無を検出し、注入攻撃や挿入攻撃が検出される場合には、異常が発生していることを示すメッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に通知することが可能となる。
　結果として、アプリケーションプロセッサ１２１２は、高速データ通信により、障害の有無に応じた特異メッセージを取得することで、特異メッセージに応じた迅速で、かつ、適切な対応が可能となる。
　＜侵害検出部によるセキュリティ部の異常検出＞
　次に、侵害検出部１５１１によるセキュリティ部１５１０の異常検出について説明する。
　セキュリティ部１５１０は、例えば、イメージセンサ１２１１内の一部または全部の動作を無効化させる、誤動作させる、偽情報を流入させる、および情報を流出させる等の注入攻撃に加えて、イメージセンサ１２１１に用いられる電力またはイメージセンサ１２１１から生じる電磁を解析することでイメージセンサ１２１１内情報を流出させる解析攻撃（電力解析攻撃、電磁解析攻撃）を受ける可能性がある。
　そこで、侵害検出部１５１１は、上述した異常検出に加えて、注入攻撃に伴うセキュリティ部１５１０内部の改竄の有無を論理的に検出したり、電力解析または電磁解析に必要な攻撃物体（例えば、プローブ）がセキュリティ部１５１０の近くに有るか無いかを物理的に検出したりすることによって、侵害に係る異常の有無を検出し、異常が検出された場合に異常メッセージを特異メッセージとして送信する。
　（侵害検出部によるセキュリティ部の異常検出処理）
　次に、図１２４のフローチャートを参照して、侵害検出部１５１１によるセキュリティ部１５１０の異常検出処理について説明する。
　ステップＳ１０８１において、侵害検出部１５１１は、セキュリティ部１５１０の論理状態を示す情報を検出する。
　ステップＳ１０８２において、侵害検出部１５１１は、検出したセキュリティ部１５１０の論理状態を示す情報に基づいて、セキュリティ部１５１０内部において改竄が発生しているか否かを判定する。
　ステップＳ１０８２において、セキュリティ部１５１０内部において改竄が発生していると判定された場合、処理は、ステップＳ１０８３に進む。
　ステップＳ１０８３において、侵害検出部１５１１は、注入攻撃に伴うセキュリティ部１５１０内の改竄が発生していることを示す第１異常メッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　ステップＳ１０８２において、セキュリティ部１５１０内部において改竄が発生していないと判定された場合、処理は、ステップＳ１０８４に進む。
　ステップＳ１０８４において、侵害検出部１５１１は、セキュリティ部１５１０の物理状態を示す情報を検出する。
　ステップＳ１０８５において、侵害検出部１５１１は、検出したセキュリティ部１５１０の物理状態を示す情報に基づいて、電力解析または電磁解析に必要な攻撃物体（例えば、プローブ）がセキュリティ部１５１０の近くに有るか否かを判定する。
　ステップＳ１０８５において、解析攻撃に用いられる電力解析または電磁解析に必要な攻撃物体（例えば、プローブ）がセキュリティ部１５１０の近くに有ると判定された場合、処理は、ステップＳ１０８６に進む。
　ステップＳ１０８６において、侵害検出部１５１１は、電力解析または電磁解析に必要な攻撃物体（例えば、プローブ）がセキュリティ部１５１０の近くに有り、電力解析攻撃や電磁解析攻撃を受ける可能性があることを示す第２異常メッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　ステップＳ１０８５において、電力解析または電磁解析に必要な攻撃物体（例えば、プローブ）がセキュリティ部１５１０の近くにないと判定された場合、処理は、ステップＳ１０８７に進む。
　ステップＳ１０８７において、侵害検出部１５１１は、イメージセンサ１２１１が正常であることを示すメッセージを特異メッセージとして、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　以上の処理により、注入攻撃に伴ったセキュリティ部１５１０の論理的な改竄の有無や解析攻撃の可能性の有無等の侵害が検出され、侵害が検出される場合には、侵害に伴った異常が発生していることを示すメッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に通知することが可能となる。
　結果として、アプリケーションプロセッサ１２１２は、高速データ通信により、侵害の有無に応じた特異メッセージを取得することで、特異メッセージに応じた迅速かつ適切な対応が可能となる。
　＜温度検出部による異常検出＞
　次に、温度検出部１５１２による異常検出について説明する。
　イメージセンサ１２１１または通信経路の動作保証温度が範囲外となるように、イメージセンサ１２１１の内部温度またはイメージセンサ１２１１の外部温度、通信経路内部温度、または通信経路外部温度が意図的に強制されるように、イメージセンサ１２１１を誤動作させる温度攻撃がある。
　そこで、温度検出部１５１２は、イメージセンサ１２１１や通信経路に対する温度攻撃の有無を検出する。
　すなわち、イメージセンサ１２１１には、動作保証温度の上限値（第１閾値）および下限値（第２閾値）があるので、イメージセンサ１２１１の温度が第１閾値（上限値）よりも高い状態、または、第２閾値（下限値）よりも低い状態であれば、温度検出部１５１２は、異常が発生していることを示すメッセージを特異メッセージとしてアプリケーションプロセッサ１２１２に通知する。
　尚、温度検出部１５１２で検出された温度が動作保証範囲内である場合、温度検出部１５１２は、正常であることを示す特異メッセージを送信するようにしてもよいし、特異メッセージを送信しないようにしてもよい。また、異常メッセージや正常メッセージの代わりに、検出された温度の値そのものが特異メッセージとして送信されるようにしてもよい。
　さらに、温度検出部１５１２は、機能安全のために複数設けられてもよく、それぞれの検出結果がそれぞれの閾値の範囲外になる場合に異常を示す特異メッセージが送信されてもよい。その場合、一部の温度検出部１５１２に異常が発生しても対処できる。
　また、特異メッセージを受信するアプリケーションプロセッサ１２１２においては、複数回取得された特異メッセージ群が解析されることによって、温度検出部１５１２に異常が発生している範囲や位置を把握することが可能となる。
　（温度検出部による異常検出処理）
　次に、図１２５のフローチャートを参照して、温度検出部１５１２による異常検出処理について説明する。
　ステップＳ１１０１において、温度検出部１５１２は、イメージセンサ１２１１内の温度を検出する。
　ステップＳ１１０２において、温度検出部１５１２は、検出したイメージセンサ１２１１の温度が第１閾値（上限値）以上であるか（第１閾値よりも高いか）否かを判定する。
　ステップＳ１１０２において、検出したイメージセンサ１２１１の温度が第１閾値（上限値）以上であると判定された場合、処理は、ステップＳ１１０３に進む。
　ステップＳ１１０３において、温度検出部１５１２は、イメージセンサ１２１１が動作保証温度以上であり、異常が発生していることを示す第１異常メッセージからなる特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　また、ステップＳ１１０２において、検出したイメージセンサ１２１１の温度が第１閾値（上限値）以上ではないと判定された場合、処理は、ステップＳ１１０４に進む。
　ステップＳ１１０４において、温度検出部１５１２は、検出したイメージセンサ１２１１の温度が第２閾値（下限値）以下であるか（第２閾値よりも低いか）否かを判定する。
　ステップＳ１１０４において、検出したイメージセンサ１２１１の温度が第２閾値（下限値）以下であると判定された場合、処理は、ステップＳ１１０５に進む。
　ステップＳ１１０５において、温度検出部１５１２は、イメージセンサ１２１１が動作保証温度以下であり、異常が発生していることを示す第２異常メッセージからなる特異メッセージを、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に通知する。
　ステップＳ１１０４において、検出したイメージセンサ１２１１の温度が第２閾値（下限値）以下ではないと判定された場合、処理は、ステップＳ１１０６に進む。
　ステップＳ１１０６において、温度検出部１５１２は、イメージセンサ１２１１の温度が動作保証温度内であり、異常が発生していないことを示す正常メッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に送信する。
　以上の処理により、イメージセンサ１２１１に対する温度攻撃が発生するような場合、画像データを送信する高速データ通信により通知されることになるので、アプリケーションプロセッサ１２１２において、迅速かつ適切な対応を実現することが可能となる。
　＜イメージセンサの状態や特性に基づいて、異常の有無を検出するアプリケーションプロセッサの詳細な構成例＞
　以上においては、イメージセンサ１２１１が、自身の異常の有無を検出して、検出結果に応じた特異メッセージをアプリケーションプロセッサ１２１２に送信する例について説明してきた。
　しかしながら、アプリケーションプロセッサ１２１２が、イメージセンサ１２１１の状態や特性を取得して、異常の有無を検出するようにしてもよい。
　図１２６は、イメージセンサ１２１１の状態や特性を取得して、異常の有無を検出するようにしたアプリケーションプロセッサ１２１２の構成例を示している。
　図１２６のアプリケーションプロセッサ１２１２は、物理層処理部１５５１、拡張モード対応CSI-2受信回路１５５２、I2C/I3Cマスタ１５５３、記憶部１５５４、コントローラ１５５５、妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０を備えて構成される。
　なお、妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０は、いずれもイメージセンサ１２１１より供給される状態や特性に応じて処理を実行するものである。しかしながら、基本的な機能は、それぞれ図１１８における妨害検出部１５０８、障害検出部１５０９、セキュリティ部１５１０、侵害検出部１５１１、および温度検出部１５１２と同様である。
　また、物理層処理部１５５１、拡張モード対応CSI-2受信回路１５５２、I2C/I3Cマスタ１５５３、記憶部１５５４、セキュリティ部１５５８、コントローラ１５５５は、図７７の物理層処理部１３２１、拡張モード対応CSI-2受信回路１３２２、I2C/I3Cマスタ１３２３、記憶部１３２４、セキュリティ部１３２６、およびコントローラ１３２７に対応する各ブロックと同様に構成され、その詳細な説明は省略する。
　妨害検出部１５５６は、拡張モード対応CSI-2受信回路１５５２を介して、イメージセンサ１２１１より供給される画像データに基づき、受光波形パターン、受光スポットパターン、受光ドットパターン、受光軌跡パターン等の何れかを記憶部１５５４内に予め格納された格納パターンと比較することによって、イメージセンサ１２１１または画像データについて正常か異常かを判断する。
　妨害検出部１５５６は、イメージセンサ１２１１または画像データについて正常か異常かの判定結果を特異メッセージとして後段に出力するようにしてもよい。
　また、イメージセンサ１２１１内およびアプリケーションプロセッサ１２１２内のそれぞれに、妨害検出部１５０８，１５７７が設けられるようにしてもよい。妨害検出部１５０８，１５７７の両方がそれぞれに設けられる場合、例えば、異常の有無を２重判断することが可能となる。このため、イメージセンサ１２１１内の妨害検出部１５０８またはアプリケーションプロセッサ１２１２内の妨害検出部１５７７の何れか一方が攻撃されても、イメージセンサ１２１１に対する妨害の有無を検出することが可能になる。
　障害検出部１５５７は、アプリケーションプロセッサ１２１２内の通信経路または物理層処理部１５５１に対して電気的に直接接続または間接接続される。
　また、イメージセンサ１２１１内およびアプリケーションプロセッサ１２１２内のそれぞれに障害検出部１５０９，１５５７が設けられてもよい。
　例えば、イメージセンサ１２１１は、自らの電気特性を測定し、画像データを送信する高速データ通信によりアプリケーションプロセッサ１２１２に対して、特異メッセージとして送信する。
　障害検出部１５５７は、「イメージセンサ１２１１＋通信経路（物理層）」内の電気特性を測定することで、キャリブレーション処理によって通信経路内の電気特性を認識する。
　ハードウエアトロイは通信経路内（例えば、ワイヤ内）に挿入することが可能なため、通信経路内の電気特性の変化が検出されることによって、ハードウエアトロイの有無を高い精度で検出することが可能になる。
　同様に、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０は、アプリケーションプロセッサ１２１２内に設けられるのみならず、イメージセンサ１２１１内に設けられるようにしてもよい。
　すなわち、セキュリティ部１５１０，１５５８、侵害検出部１５１１，１５５９、および温度検出部１５１２，１５６０が、イメージセンサ１２１１内およびアプリケーションプロセッサ１２１２内のそれぞれに設けられてもよい。
　妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０の何れかは、メモリと電気的に直接接続されてもよい。
　このメモリは上述したレジスタと電気的に直接接続されてもよく、妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０の何れかは、レジスタと電気的に直接接続されてもよい。
　メモリは、メモリ内情報の漏洩または改竄の何れかから保護されたメモリであってもよい。ここでメモリおよびレジスタを記憶部１５５４と総称する。妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０の何れかは、例えば、複数回の検出結果を記憶部１５５４内へ保存することによって、短時間内で連続妨害、連続障害、および連続侵害のいずれかを受けていると判断することや、長時間にわたって温度負荷があると判断することが可能であり、そのような状況を示す異常メッセージが送信されてもよい。
　なお、格納パターン、閾値、第１閾値、および第２閾値の何れかは、記憶部１５５４から読み出されてもよい。また、格納パターン、閾値、第１閾値、および第２閾値の何れかは、I2CまたはI3Cを少なくとも介し、アプリケーションプロセッサ１２１２がイメージセンサ１２１１内の記憶部１５０７内に書き込んでもよい。
　このように、検出結果がアプリケーションプロセッサ１２１２外の、例えば、イメージセンサ１２１１内の保護された記憶部１５０７内に定期的に保存されることにより、アプリケーションプロセッサ１２１２内で事故が生じた際に、外部のイメージセンサ１２１１内の保護された記憶部１５０７が解析されることによって、事故発生の原因を特定し易くすることが可能となる。同様に、検出結果がイメージセンサ１２１１外の、例えば、アプリケーションプロセッサ１２１２内の保護された記憶部１５５４内に定期的に保存されることにより、イメージセンサ１２１１内で事故が生じた際に、外部のアプリケーションプロセッサ１２１２内の保護された記憶部１５５４が解析されることによって、事故発生の原因を特定し易くすることが可能となる。
　妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０の何れかは、それぞれ拡張モード対応CSI-2受信回路１５５２に対して電気的に直接接続され、それぞれの検出結果が直接的に拡張モード対応CSI-2受信回路１５５２から伝達されるようにしてもよい。
　また、妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０の何れかは、それぞれ拡張モード対応CSI-2受信回路１５５２に対して記憶部１５５４などを介して電気的に間接接続され、それぞれの検出結果が間接的に拡張モード対応CSI-2受信回路１５５２から伝達されるようにしてもよい。
　さらに、特異メッセージは、拡張モード対応CSI-2受信回路１５５２から直接的に出力されてもよいし、記憶部１５５４などを介して拡張モード対応CSI-2受信回路１５５２から間接的に出力されてもよい。
　また、妨害検出部１５５６、障害検出部１５５７、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０の何れかは、それぞれ通信経路に対して電気的に直接接続、または記憶部１５５４などを介して電気的に間接接続されてもよい。
　なお、少なくとも高速データ送信に用いられる通信経路は、低速コマンド送信のみに用いられる通信経路よりも、高周波特性に優れるので攻撃検出に対する感度が高いと考えられる。
　また、高速データ送信に用いられる通信経路の一部または全部を介してイメージセンサ１２１１に電力供給がなされる場合、この電力供給を少なくとも一時的に無効化するだけでイメージセンサ１２１１の動作や画像データストリームを無効化できる。
　例えば、高速データ送信に用いられる通信経路の一部または全部が、ハードウエアトロイが挿入された通信経路と置き換えられ、ハードウエアトロイが無線起動またはタイマ起動されるだけで、移動体装置（推進装置）の事故が簡単に誘発される可能性がある。つまり、障害検出部１５５７は、低速コマンド送信に特化した通信経路よりも少なくとも高速データ送信に用いられる物理層に対して好適であり、さらに電力伝送にも用いられる物理層に対して特に好適である。
　妨害検出部１５０８，１５５６、障害検出部１５０９，１５５７、セキュリティ部１５１０，１５５８、侵害検出部１５１１，１５５９、および温度検出部１５１２，１５６０の何れかは、それぞれ他ブロック内へ含まれてもよい。
　例えば、妨害検出部１５０８は、画素１５０１、AD変換器１５０２、画像処理部１５０３、記憶部１５０７、および拡張モード対応CSI-2送信回路１５０４の何れかに少なくとも一部が含まれてもよい。
　また、例えば、妨害検出部１５５６は、拡張モード対応CSI-2受信回路１５５２、および記憶部１５５４の何れかに少なくとも一部が含まれてもよい。
　さらに、例えば、障害検出部１５０９は、物理層処理部１５０５、記憶部１５０７、および拡張モード対応CSI-2送信回路１５０４の何れかに少なくとも一部が含まれてもよい。
　また、例えば、障害検出部１５５７は、拡張モード対応CSI-2受信回路１５５２および記憶部１５５４の何れかに少なくとも一部が含まれてもよい。
　さらに、例えば、セキュリティ部１５１０、侵害検出部１５１１、温度検出部１５１２の何れかは、それぞれ、記憶部１５０７、および拡張モード対応CSI-2送信回路１５０４の何れかに少なくとも一部が含まれてもよい。
　また、例えば、セキュリティ部１５５８、侵害検出部１５５９、および温度検出部１５６０の何れかは、それぞれ、記憶部１５５４、および拡張モード対応CSI-2受信回路１５５２の何れかに少なくとも一部が含まれてもよい。
　また、画素１５０１、AD変換器１５０２、画像処理部１５０３、物理層処理部１５０５、拡張モード対応CSI-2送信回路１５０４、拡張モード対応CSI-2受信回路１５５２、記憶部１５０７，１５５４、I2C/I3Cスレーブ１５０６、I2C/I3Cマスタ１５５３、妨害検出部１５０８，１５５６、障害検出部１５０９，１５５７、セキュリティ部１５１０，１５５８、侵害検出部１５１１，１５５９、および温度検出部１５１２，１５６０の何れかは、それぞれ、移動体装置（推進装置）のコントローラ、若しくは制御部、または図示しない新たな制御部によって直接的または間接的に制御されてもよい。
　＜アプリケーションプロセッサによる、イメージセンサの異常の有無を検出する処理＞
　次に、図１２７，図１２８のフローチャートを参照して、アプリケーションプロセッサによる、イメージセンサの異常の有無を検出する処理について説明する。
　なお、図１２７のフローチャートがイメージセンサ１２１１の処理を表しており、図１２８のフローチャートがアプリケーションプロセッサ１２１２の処理を表している。
　ステップＳ１１３１（図１２７）において、イメージセンサ１２１１は、異常の有無を判定するのに必要とされる自らの状態または特性を検出する。
　より詳細には、上述したイメージセンサ１２１１における妨害検出部１５０８、障害検出部１５０９、侵害検出部１５１１、および温度検出部１５１２のそれぞれがイメージセンサ１２１１内における異常の有無を判定する際に必要とされる状態または特性を検出する。
　ただし、この処理においては、各種の状態または特性が検出されるのみであり、異常の有無については判定されない。
　ステップＳ１１３２において、イメージセンサ１２１１は、検出した自らの状態または特性を、特異メッセージとして、画像データを送信する高速データ通信により送信する。
　より詳細には、妨害検出部１５０８、障害検出部１５０９、侵害検出部１５１１、および温度検出部１５１２のそれぞれがイメージセンサ１２１１内における異常の有無を判定する際に必要とされる状態または特性を、特異メッセージとして、画像データを送信する高速データ通信により送信する。
　尚、以上のようなイメージセンサ１２１１の妨害検出部１５０８、障害検出部１５０９、侵害検出部１５１１、および温度検出部１５１２によりなされる処理は、以降においては、単に、イメージセンサ１２１１が自らの状態または特性を検出する、および、イメージセンサ１２１１が、検出した自らの状態または特性を、アプリケーションプロセッサ１２１２に送信する、といった簡略な表現とする。
　ステップＳ１１５１（図１２８）において、アプリケーションプロセッサ１２１２は、イメージセンサ１２１１より送信されてくる特異メッセージを受信したか否かを判定する。
　より詳細には、アプリケーションプロセッサ１２１２の妨害検出部１５５６、障害検出部１５５７、侵害検出部１５５９、および温度検出部１５６０は、それぞれイメージセンサ１２１１の妨害検出部１５０８、障害検出部１５０９、侵害検出部１５１１、および温度検出部１５１２の少なくともいずれかからの特異メッセージを受信したか否かを判定する。ただし、セキュリティ部１５５８、コントローラ１５５５、拡張モード対応CSI-2受信回路１５５２、および物理層処理部１５５１などの何れかが、イメージセンサ１２１１の妨害検出部１５０８、障害検出部１５０９、侵害検出部１５１１、および温度検出部１５１２の少なくともいずれかからの特異メッセージを受信したか否かを判定してもよい。
　ステップＳ１１５１において、特異メッセージが受信されたと判定された場合、処理は、ステップＳ１１５２に進む。
　ステップＳ１１５２において、アプリケーションプロセッサ１２１２は、特異メッセージとして送信されてきたイメージセンサ１２１１の状態または特性を検出する。
　より詳細には、アプリケーションプロセッサ１２１２の妨害検出部１５５６、障害検出部１５５７、侵害検出部１５５９、および温度検出部１５６０の少なくとも何れかは、受した特異メッセージに含まれるそれぞれの異常を検出するための状態または特性を検出する。
　ステップＳ１１５３において、アプリケーションプロセッサ１２１２は、検出したイメージセンサ１２１１の状態または特性に対してキャリブレーション処理を掛けることにより補正する。
　より詳細には、アプリケーションプロセッサ１２１２の妨害検出部１５５６、障害検出部１５５７、侵害検出部１５５９、および温度検出部１５６０の少なくとも何れかは、検出した状態または特性に対してキャリブレーション処理を掛けて補正する。ただし、セキュリティ部１５５８、コントローラ１５５５、拡張モード対応CSI-2受信回路１５５２、および物理層処理部１５５１などの何れかが、検出した状態または特性に対してキャリブレーション処理を掛けて補正してもよい。
　ステップＳ１１５４において、アプリケーションプロセッサ１２１２は、キャリブレーション処理により補正したイメージセンサ１２１１の状態または特性が正常とみなされる閾値範囲外であるのか否かを判定する。
　より詳細には、アプリケーションプロセッサ１２１２の妨害検出部１５５６、障害検出部１５５７、侵害検出部１５５９、および温度検出部１５６０の少なくとも何れかは、キャリブレーション処理により補正した状態または特性が正常とみなされる閾値範囲外であるのか否かを判定する。ただし、セキュリティ部１５５８、コントローラ１５５５、拡張モード対応CSI-2受信回路１５５２、および物理層処理部１５５１などの何れかが、キャリブレーション処理により補正した状態または特性が正常とみなされる閾値範囲外であるのか否かを判定してもよい。尚、それぞれの状態または特性が正常とみなされる閾値範囲外であるか否かの判定に係る具体的な処理は、図１１９，図１２２乃至図１２５のフローチャートを参照して説明した処理である。
　ステップＳ１１５４において、状態または特性が正常とみなされる閾値範囲外であると判定される場合、処理は、ステップＳ１１５５に進む。
　ステップＳ１１５５において、アプリケーションプロセッサ１２１２は、イメージセンサ１２１１が異常であるものとみなす。
　また、ステップＳ１１５４において、状態または特性が正常とみなされる閾値範囲外でないと判定される場合、処理は、ステップＳ１１５６に進む。
　ステップＳ１１５６において、アプリケーションプロセッサ１２１２は、イメージセンサ１２１１が正常であるものとみなす。
　すなわち、アプリケーションプロセッサ１２１２のセキュリティ部１５５８、コントローラ１５５５、拡張モード対応CSI-2受信回路１５５２、物理層処理部１５５１、妨害検出部１５５６、障害検出部１５５７、侵害検出部１５５９、および温度検出部１５６０の少なくとも何れかにおいて、キャリブレーション処理により補正した状態または特性が正常とみなされる閾値範囲外であると判定された場合、イメージセンサ１２１１が異常であるとみなされ、閾値範囲外ではないと判定された場合、イメージセンサ１２１１が正常であるとみなされる。
　以上の処理により、アプリケーションプロセッサ１２１２においても、イメージセンサ１２１１の異常の有無を判定することが可能となり、イメージセンサ１２１１において異常が発生しても、アプリケーションプロセッサ１２１２により、迅速かつ適切な対応を可能となる。
　尚、上述したアプリケーションプロセッサ１２１２の妨害検出部１５５６、障害検出部１５５７、侵害検出部１５５９、および温度検出部１５６０によるイメージセンサ１２１１の異常の有無を判定する処理については、単に、アプリケーションプロセッサ１２１２が、イメージセンサ１２１１の状態または特性に基づいて、イメージセンサ１２１１の異常の有無を判定する処理、または異常診断（処理）と称する。ただし、アプリケーションプロセッサ１２１２が、イメージセンサ１２１１の状態や特性を取得しないで、異常の有無を検出するようにしてもよい。つまり、アプリケーションプロセッサ１２１２の妨害検出部１５５６、障害検出部１５５７、侵害検出部１５５９、および温度検出部１５６０のそれぞれがアプリケーションプロセッサ１２１２内における異常の有無を判定する際に必要とされる状態または特性を検出し、異常の有無を判定してもよい。
　＜画像データの高速データ送信を阻害せずに、特異メッセージの高速データ送信が実行される例＞
　以上においては、特異メッセージが、画像データの高速データ送信されることを前提としてきたが、送信タイミングを考慮せずに、高速データ送信がなされると、画像データの高速データ送信が阻害される恐れがある。
　そこで、画像データの高速データ送信を阻害せずに、特異メッセージの高速データ送信を実現する例について説明する。
　画像データの高速データ送信を阻害せずに特異メッセージの高速データ送信を実現するには、画像データの高速データ送信の各種データの送信タイミングに合わせた送信が必要となる。
　このため、特異メッセージは、画像データを送信する際の、フレームスタートからフレームエンドまでの期間内、またはフレームエンドからフレームスタートまでの期間内（フレームブランキング期間）とする必要がある。
　ここで、フレームスタートからフレームエンドまでの期間内で、特異メッセージを送信できるのは、例えば、図１２９で示されるように、フレームスタート内、埋込データ内、画像データ内、非画像データ（読み出し応答、およびユーザ定義データ）内、フレームエンド内、ラインブランキング期間内の何れかである。なお、例えばCCIチャネルをVC0に割り当てる場合、図１２９内のVC0をVC1に、図１２９内のVC1をVC2に、それぞれ置き換えてもよい。
　なお、以降においては、画像データの高速データ送信と特異メッセージの高速データ送信とが、並列実行ではなく直列実行される例を説明する。ただし、画像データの高速データ送信と特異メッセージの送信（高速データ送信または低速コマンド送信）とで通信経路が異なる場合、並列実行されてもよい。
　また、高速データ送信と低速コマンド送信とは、フィルタによる周波数分離が可能なので、消費電力に問題なければ、送信の一部または全部が重複（並列実行）されていても構わない。
　さらに、上述したイメージセンサ１２１１による自らの異常の有無の検出処理、および、イメージセンサ１２１１からの状態または特性に基づいたアプリケーションプロセッサ１２１によるイメージセンサ１２１１の異常の有無の検出処理については、以降において、それぞれイメージセンサ１２１１による異常診断（処理）、およびアプリケーションプロセッサ１２１２による異常診断（処理）と称する。
　ここで、イメージセンサ１２１１における異常診断（処理）は、イメージセンサ１２１１が自らの状態または特性にもとづいて異常の有無を判定する場合については、イメージセンサ１２１１による自らの異常の有無が判定される一連の処理が異常診断（処理）となる。
　一方、イメージセンサ１２１１の状態または特性に基づいて、アプリケーションプロセッサ１２１２において、イメージセンサ１２１１の異常診断（処理）がなされる場合については、イメージセンサ１２１１における異常診断（処理）は、自らの状態または特性を検出するのみの（異常の有無は判定されない）処理となる。
　また、所定の時間間隔や所定の動作間隔でなされる異常診断については、定期異常診断と称し、処理の最初になされる異常診断については、初期異常診断と称する。
　定期異常診断の結果である特異メッセージは、ベンダ固有コード（Vendor specific）またはリザーブドコード（Reserved for future use）またはリザーブドコードから特異メッセージとして新たに定義されるコードを示す埋込データの少なくとも一部内に格納されて送信されるようにしてもよい。
　また、特異メッセージは、新たに定義されるパケット内に格納されて送信されてもよく、ユーザ定義領域パケット内またはリザーブド領域パケット内に格納されて送信されてもよい。
　例えば、拡張パケットヘッダのうちリザーブド領域の一部または全部が、特異メッセージとして新たに定義されるようにしてもよい。また、例えば、拡張パケットヘッダのうちユーザ定義領域（例えば、User defined metadata）の一部または全部が、特異メッセージとして新たに定義されるようにしてもよい。
　また、例えば、既に定義されている拡張パケットヘッダや拡張パケットフッタのそれぞれの一部または全部が、特異メッセージとして流用されるようにしてもよい。
　ただし、特異メッセージは、拡張パケットフッタ内よりも拡張パケットヘッダ内へ格納される方が、即時性が高い（移動体装置の処理において直ぐに異常を認識できる）。特異メッセージは、拡張パケットフッタePF1やePF0の一部または全部であってもよい。特異メッセージが拡張パケットヘッダ内または拡張パケットフッタ内に格納される場合、後方互換を得られる効果もある。
　＜画像データの高速データ送信を阻害せずに、特異メッセージの高速データ送信が実行される場合の処理＞
　次に、図１３０のフローチャートを参照して、画像データの高速データ送信を阻害せずに、特異メッセージの高速データ送信が実行される場合のイメージセンサ１２１１の処理について説明する。
　ステップＳ１１７１において、イメージセンサ１２１１は、初期異常診断を実行する。
　ステップＳ１１７２において、イメージセンサ１２１１（の拡張モード対応CSI-2送信回路１５０４）は、高速データ送信の開始命令を受信したか否かを判定し、高速データ送信の開始命令を受信したと判定されるまで、処理が待機される。そして、ステップＳ１１７２において、拡張モード対応CSI-2送信回路１５０４が、高速データ送信の開始命令を受信したと判定した場合、処理はステップＳ１１７３に進む。
　ステップＳ１１７３において、イメージセンサ１２１１は、初期異常診断によりイメージセンサ１２１１において初期異常が発生しているか否かを判定する。
　ステップＳ１１７３において、初期異常があると判定された場合、処理は、ステップＳ１１７４に進む。
　ステップＳ１１７４において、イメージセンサ１２１１（の拡張モード対応CSI-2送信回路１５０４）は、初期異常メッセージを送信する。
　すなわち、この場合、以降においては、撮像送信処理がなされない。
　一方、ステップＳ１１７３において、初期異常が発生していないと判定された場合、処理は、ステップＳ１１７５に進む。
　ステップＳ１１７５において、イメージセンサ１２１１は、撮像送信処理を実行して、画素１５０１により撮像され、AD変換器１５０２によりAD変換され、画像処理部１５０３により画像処理された画像データが拡張モード対応CSI-2送信回路１５０４に供給され、アプリケーションプロセッサ１２１２に送信される。
　＜撮像送信処理（その１）＞
　ここで、図１３１のフローチャートを参照して、撮像送信処理（その１）について説明する。
　ステップＳ１１９１おいて、画素１５０１が撮像を開始し、画素１５０１から出力される画像データが、AD変換器１５０２および画像処理部１５０３を介して拡張モード対応CSI-2送信回路１５０４に供給される。
　ステップＳ１１９２において、イメージセンサ１２１１は、定期異常診断を実行する。
　ステップＳ１１９３において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルのフレームスタートを送信する。
　ステップＳ１１９４において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの埋込データを送信する。このとき、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの埋込データ内に定期異常診断の診断結果となる特異メッセージを含めて送信する。
　ステップＳ１１９５において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの画像データを送信する。
　ステップＳ１１９６において、拡張モード対応CSI-2送信回路１５０４は、１フレーム分の画像データの送信が完了したか否かを判定する。
　ステップＳ１１９６において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了していないと判定した場合、処理はステップＳ１１９５に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１１９６において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了したと判定した場合、処理はステップＳ１１９７に進む。
　ステップＳ１１９７において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルのフレームエンドを送信する。
　ステップＳ１１９８において、拡張モード対応CSI-2送信回路１５０４は、高速データ送信の終了命令を受信したか否かを判定する。
　ステップＳ１１９８において、拡張モード対応CSI-2送信回路１５０４が、高速データ送信の終了命令を受信していないと判定した場合、処理はステップＳ１１９１に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１１９８において、拡張モード対応CSI-2送信回路１５０４が、高速データ送信の終了命令を受信したと判定した場合、処理は終了される。
　撮像送信処理は、高速データ送信の終了命令を受信するまで継続実行されてもよく、高速データ送信の開始命令を受信するたびに実行されてもよい。
　以上の処理により、画像データの高速データ送信を阻害することなく、特異メッセージを高速データ送信することが可能となる。
　＜撮像送信処理の応用例＞
　以上においては、撮像送信処理が、高速データ送信の終了命令が受信された場合に処理を終了させる例について説明してきたが、高速データ送信の開始命令が受信されない場合に処理を終了させてもよい。
　図１３２のフローチャートは、高速データ送信の開始命令が受信されない場合に処理を終了させるようにした撮像送信処理の応用例を示している。
　尚、図１３２のステップＳ１２１１乃至Ｓ１２１７の処理については、図１３１のステップＳ１１９１乃至Ｓ１１９７と同様の処理であるので、その説明は省略する。
　すなわち、ステップＳ１２１８において、拡張モード対応CSI-2送信回路１５０４が、高速データ送信の開始命令を受信していると判定した場合、処理はステップＳ１２１１に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１２１８において、拡張モード対応CSI-2送信回路１５０４が、高速データ送信の開始命令を受信していないと判定した場合、処理は終了される。
　以上の処理においても、画像データの高速データ送信を阻害することなく、特異メッセージを高速データ送信することが可能となる。
　＜撮像送信処理（その２）＞
　以上においては、定期異常診断の診断結果となる特異メッセージが、埋込データに含めて送信される例について説明してきたが、２回目の定期異常診断（第２定期異常診断）を実行して、第２埋込データに含められて送信されるようにしてもよい。
　図１３３は、２回目の定期異常診断（第２定期異常診断）を実行して、第２定期異常診断の診断結果となる特異メッセージが第２埋込データに含められて送信されるようにした撮像送信処理を説明するフローチャートである。
　なお、図１３３のステップＳ１２３１，Ｓ１２３３，Ｓ１２３５，Ｓ１２３６，Ｓ１２３９，Ｓ１２４０の処理は、図１３１のステップＳ１１９１，Ｓ１１９３，Ｓ１１９５乃至Ｓ１１９８の処理と同様であるので、その説明は、省略する。
　すなわち、ステップＳ１２３１の処理により拡張モード対応CSI-2送信回路１５０４に画像データ供給されると、ステップＳ１２３２において、イメージセンサ１２１１は、１回目の定期異常診断（第１定期異常診断）を実行する。
　ステップＳ１２３３において、バーチャルチャネルのフレームスタートが送信されると、ステップＳ１２３４において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの第１埋込データを送信する。このとき、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの第１埋込データ内に第１定期異常診断の診断結果となる特異メッセージを含めて送信する。
　ステップＳ１２３５，Ｓ１２３６において、１フレーム分の画像データの送信が完了すると、ステップＳ１２３７において、イメージセンサ１２１１は、２回目の定期異常診断（第２定期異常診断）を実行する。
　ステップＳ１２３８において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの第２埋込データを送信する。このとき、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの第２埋込データ内に第２定期異常診断の診断結果となる特異メッセージを含めて送信する。
　そして、ステップＳ１２３９において、バーチャルチャネルのフレームエンドが送信されて、ステップＳ１２４０において、高速データ送信の終了命令を受信すると、処理は終了される。
　以上の処理により、画像データの高速データ送信を阻害することなく、特異メッセージを高速データ送信することが可能となる。
　また、以上の処理においては、第２定期異常診断がラインブランキング期間内に実行されるため、消費電力の最大値へ影響を与えない（送信と同時には定期異常診断しない）。さらに、定期異常診断はラインブランキング期間外に実行されるようにしてもよい。
　また、定期異常診断の診断結果に対応する特異メッセージが、フレームスタート直後およびフレームエンド直前の埋込データ内へ格納されため、移動体装置（推進装置）が異常発生タイミングを判断することが可能となる。例えば、異常が、連続的に発生しているのか、画像データ送信前に発生しているのか、画像データ送信後に発生しているのかを判定することが可能となる。なお、最初の埋込データが構成されないようにしてもよい。また、第１定期異常診断が実行されず、第２定期異常診断のみが実行される構成でもよい。
　＜撮像送信処理（その３）＞
　以上においては、２回目の定期異常診断（第２定期異常診断）を実行して、第２定期異常診断の診断結果に対応する特異メッセージが、第２埋込データに含められて送信されるようにする例について説明してきたが、定期異常診断の診断結果を読み出し応答に含めて送信するようにしてもよい。
　すなわち、低速コマンド送信のマスタであるアプリケーションプロセッサ１２１２は、低速コマンド送信のスレーブであるイメージセンサ１２１１から高速データ送信によって送信されたフレームスタート信号が受信される場合、イメージセンサ１２１１内の特異メッセージをアプリケーションプロセッサ１２１２に読み出すことを要求する読み出し命令を低速コマンド送信によって送信する。
　イメージセンサ１２１１は、アプリケーションプロセッサ１２１２から送信された読み出し命令を受信し、読み出し命令に応じた特異メッセージを含む読み出し応答を高速データ送信によって送信する。
　アプリケーションプロセッサ１２１２は、特異メッセージを含む読み出し応答を受信することによって、イメージセンサ１２１１からの特異メッセージの通知を受信することができる。
　つまり、特異メッセージは、フレームスタートとフレームエンドとの間の画像データが送信されないラインブランキングの期間内に送信されてもよく、特にフレームスタートと画像データの間の期間内に送信されることが望ましい。この読み出し命令は、例えば、I2CまたはI3Cの規格におけるRead/WriteのReadに相当する。読み出し応答は、Read戻り値に相当する。これにより、消費電力の最大値へ影響を与えずに、画像データの送信前に異常を迅速に通知することが可能となる。
　ここで、図１３４，図１３５のフローチャートを参照して、定期異常診断の診断結果を読み出し応答に含めて送信するようにした撮像送信処理を説明する。
　なお、図１３４のフローチャートがイメージセンサ１２１１の処理を表しており、図１３５のフローチャートがアプリケーションプロセッサ１２１２の処理を表している。
　また、ステップＳ１２５１乃至１２５３，Ｓ１２５７乃至Ｓ１２６０の処理は、図１３１のステップＳ１１９１乃至Ｓ１１９３，Ｓ１１９５乃至Ｓ１１９８の処理と同様であるので、その説明は省略する。
　すなわち、ステップＳ１２５１乃至Ｓ１２５３（図１３４）において、撮像が開始され、定期異常診断が実行され、フレームスタートが送信される。また、ステップＳ１２７１（図１３５）において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１５５２は、イメージセンサ１２１１より送信されてきたフレームスタートを受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　そして、ステップＳ１２７１において、イメージセンサ１２１１より送信されてきたフレームスタートを受信したと判定された場合、処理は、ステップＳ１２７２に進む。
　ステップＳ１２７２において、拡張モード対応CSI-2受信回路１５５２は、低速コマンド送信により、読み出し命令をイメージセンサ１２１１に送信する。
　これに応じて、ステップＳ１２５４（図１３４）において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１５０４は、アプリケーションプロセッサ１２１２から送信された読み出し命令を受信したか否かを判定し、受信したと判定するまで、同様の処理を繰り返す。
　そして、ステップＳ１２５４において、読み出し命令を受信したと判定した場合、処理は、ステップＳ１２５５に進む。
　ステップＳ１２５５において、拡張モード対応CSI-2送信回路１５０４は、定期異常診断の診断結果となる特異メッセージを含む読み出し応答を、画像データを送信する高速データ送信により、アプリケーションプロセッサ１２１２に対して送信する。
　これに応じて、ステップＳ１２７３（図１３５）において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１５５２は、イメージセンサ１２１１より送信されてきた定期異常診断の診断結果となる特異メッセージを含む読み出し応答を受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　そして、ステップＳ１２７３において、イメージセンサ１２１１より送信されてきた定期異常診断の診断結果となる特異メッセージを含む読み出し応答を受信したと判定された場合、処理は、ステップＳ１２７４に進む。
　ステップＳ１２７４において、アプリケーションプロセッサ１２１２は、受信した読み出し応答に含まれる特異メッセージに基づいて、イメージセンサ１２１１の正常または異常を判定する。
　ステップＳ１２７５において、アプリケーションプロセッサ１２１２は、高速データ送信の終了命令を送信するか否かを判定し、終了しないと判定した場合、処理は、ステップＳ１２７１に戻り、それ以降の処理が繰り返される。
　そして、ステップＳ１２７５において、高速データ送信の終了命令を送信すると判定した場合、ステップＳ１２７６において、拡張モード対応CSI-2受信回路１５５２が、イメージセンサ１２１１に対して高速データ送信の終了命令を送信し、処理が終了する。
　なお、この処理においては、ステップＳ１２５６においては、埋込データに定期異常診断の診断結果となる特異メッセージは含まれない状態で送信されるようにしてもよい。
　以上の処理により、定期異常診断の診断結果を読み出し応答に含めて送信することが可能となる。
　＜撮像送信処理（その４）＞
　以上においては、フレームスタートに応じて読み出し命令を送信して、定期異常診断の診断結果となる特異メッセージを読み出し応答に含めて送信する例について説明してきたが、フレームエンドに応じて読み出し命令を送信して、定期異常診断の診断結果を読み出し応答に含めて送信するようにしてもよい。
　低速コマンド送信のマスタであるアプリケーションプロセッサ１２１２は、低速コマンド送信のスレーブであるイメージセンサ１２１１から高速データ送信によって送信されたフレームエンド信号が受信される場合、イメージセンサ１２１１内の特異メッセージをアプリケーションプロセッサ１２１２に対して読み出すことを要求する読み出し命令を低速コマンド送信によって送信する。
　イメージセンサ１２１１は、アプリケーションプロセッサ１２１２から送信された読み出し命令を受信し、それに応じた特異メッセージ（読み出し応答）を高速データ送信によって送信する。
　そして、アプリケーションプロセッサ１２１２は読み出し応答を受信することによって、イメージセンサ１２２からの特異メッセージの通知を取得する。
　つまり、特異メッセージは、フレームエンドと次のフレームスタートとの間の画像データが送信されないフレームブランキングの期間内に送信される。
　ここで、図１３６，図１３７のフローチャートを参照して、フレームエンドに応じて読み出し命令を送信して、定期異常診断の診断結果を読み出し応答に含めて送信するようにした撮像送信処理について説明する。
　図１３６のフローチャートは、イメージセンサ１２１１の処理を表しており、図１３７のフローチャートは、アプリケーションプロセッサ１２１２の処理を表している。
　また、図１３６のステップＳ１２９１乃至Ｓ１２９７，Ｓ１３００の処理は、図１３４のステップＳ１２５１乃至Ｓ１２５３，Ｓ１２５６乃至Ｓ１２６０の処理と同様であるので、その説明は省略する。
　さらに、図１３７のステップＳ１３１２乃至Ｓ１３１６の処理は、図１３５のステップＳ１２７２乃至Ｓ１２７６の処理と同様であるので、その説明は省略する。
　すなわち、イメージセンサ１２１１において、ステップＳ１２９１乃至Ｓ１２９７（図１３６）の処理により、画像が撮像され、定期異常診断が実行され、フレームスタート、埋込データ、画像データ、およびフレームエンドが送信される。
　これに応じて、ステップＳ１３１１（図１３７）において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１５５２は、イメージセンサ１２１１より送信されてきたフレームエンドを受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　そして、ステップＳ１３１１において、イメージセンサ１２１１より送信されてきたフレームエンドを受信したと判定された場合、処理は、ステップＳ１３１２に進む。
　ステップＳ１３１２において、拡張モード対応CSI-2受信回路１５５２は、低速コマンド送信により、読み出し命令をイメージセンサ１２１１に送信する。
　これに応じて、ステップＳ１２９８（図１３６）において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１５０４は、アプリケーションプロセッサ１２１２から送信された読み出し命令を受信したか否かを判定し、受信したと判定するまで、同様の処理を繰り返す。
　そして、ステップＳ１２９８において、読み出し命令を受信したと判定した場合、処理は、ステップＳ１２９９に進む。
　ステップＳ１２９９において、拡張モード対応CSI-2送信回路１５０４は、定期異常診断の診断結果となる特異メッセージを含む読み出し応答を、画像データを送信する高速データ送信により、アプリケーションプロセッサ１２１２に対して送信する。
　これに応じて、ステップＳ１３１３乃至Ｓ１３１６（図１３５）の処理により、アプリケーションプロセッサ１２１２において、イメージセンサ１２１１より送信されてきた定期異常診断の診断結果となる特異メッセージを含む読み出し応答が受信され、イメージセンサ１２１１の正常または異常が判定され、高速データ送信の終了命令が送信されると処理が終了する。
　以上の処理により、フレームエンドに応じて読み出し命令を送信して、定期異常診断の診断結果を読み出し応答に含めて送信することが可能となる。
　結果として、特異メッセージを、フレームエンドと次のフレームスタートとの間の画像データが送信されないフレームブランキングの期間内に送信することが可能となる。
　＜撮像送信処理（その５）＞
　以上においては、フレームエンドに応じて読み出し命令を送信して、定期異常診断の診断結果を読み出し応答に含めて送信する例について説明してきたが、フレームスタート送信の直前に、特異メッセージを含む読み出し応答が送信できるようにしてもよい。
　すなわち、例えば、イメージセンサ１２１１においては、フレームエンドが送信されてから、次のフレームスタートが送信されるまでの間に定期異常診断が実行されるようにする。そして、アプリケーションプロセッサ１２１２においては、フレームエンドが受信されてから、イメージセンサ１２１１において定期異常診断が完了するまで、所定時間だけ待機してから、読み出し命令を送信する。尚、時間をカウントするタイマが設けられるようにして、タイマにより待機時間がカウントされるようにしてもよい。
　このような処理により、２番目以降のフレームの画像データを送信する前に、イメージセンサ１２１１の動作に異常が生じる可能性があること、または異常が生じたことを、消費電力の最大値に対して影響することなく、イメージセンサ１２１１からアプリケーションプロセッサ１２１２に対して最短時間で通知することが可能となる。
　ここで、図１３８，図１３９のフローチャートを参照して、フレームエンドに応じて読み出し命令を送信して、定期異常診断の診断結果を読み出し応答に含めて送信するようにした撮像送信処理について説明する。
　図１３８のフローチャートは、イメージセンサ１２１１の処理を表しており、図１３９のフローチャートは、アプリケーションプロセッサ１２１２の処理を表している。
　また、図１３８のステップＳ１３３１乃至Ｓ１３３６，Ｓ１３３９乃至Ｓ１３４０の処理は、図１３６のステップＳ１２９１，Ｓ１２９３乃至Ｓ１２９９の処理と同様であるので、その説明は省略する。
　さらに、図１３９のステップＳ１３５１，Ｓ１３５３乃至Ｓ１３５７の処理は、図１３７のステップＳ１３１１乃至Ｓ１３１６の処理と同様であるので、その説明は省略する。
　すなわち、ステップＳ１３３１乃至Ｓ１３３６（図１３８）において、画像が撮像され、フレームスタート、埋込データ、画像データ、フレームエンドが送信されると、ステップＳ１３３７において、画素１５０１が撮像を開始し、画素１５０１から出力される画像データが、AD変換器１５０２および画像処理部１５０３を介して拡張モード対応CSI-2送信回路１５０４に供給される。
　ステップＳ１３３８において、イメージセンサ１２１１は、定期異常診断を実行する。
　一方、アプリケーションプロセッサ１２１２においては、ステップＳ１３５１（図１３９）において、フレームエンドが受信されると、ステップＳ１３５２において、所定時間だけ待機する。この所定時間は、イメージセンサ１２１１におけるステップＳ１３３８の定期異常診断の処理が完了するまでの時間である。
　そして、ステップＳ１３５２の処理により処理時間だけ待機すると、処理は、ステップＳ１３５３に進み、読み出し命令がイメージセンサ１２１１に送信される。
　イメージセンサ１２１１においては、ステップＳ１３３９，Ｓ１３４０（図１３８）の処理により、読み出し命令に応じて、定期異常診断の診断結果に応じた特異メッセージを含む読み出し応答が、画像データを送信する高速データ送信によりアプリケーションプロセッサ１２１２に送信される。尚、ステップＳ１３４１において、高速データ送信の終了命令を受信しない場合、処理は、ステップＳ１３３２の処理に戻り、それ以降の処理が繰り返される。そして、ステップＳ１３４１において、高速データ送信の終了命令が受信されると、処理が終了する。
　以上の処理により、２番目以降のフレームの画像データを送信する前に、イメージセンサ１２１１の動作異常の可能性または動作異常を、消費電力の最大値に対して影響することなく、アプリケーションプロセッサ１２１２に対して迅速に通知することが可能となる。
　＜撮像送信処理（その６）＞
　以上においては、フレームスタート送信の直前に、特異メッセージを含む読み出し応答が送信できるようにする例について説明してきたが、読み出し命令送信または読み出し応答送信は、埋込データ送信後のラインブランキング期間内に実施されるようにしてもよい。
　このような処理により、画像データを送信する前に、イメージセンサ１２１１の動作異常の可能性、または動作異常の発生を、消費電力の最大値に対して影響を与えることなく、アプリケーションプロセッサ１２１２に迅速に通知することが可能となる。
　ここで、図１４０，図１４１のフローチャートを参照して、読み出し命令送信または読み出し応答送信は、埋込データ送信後のラインブランキング期間内に実施されるようにした撮像送信処理について説明する。
　図１４０のフローチャートは、イメージセンサ１２１１の処理を表しており、図１４１のフローチャートは、アプリケーションプロセッサ１２１２の処理を表している。
　また、図１４０のステップＳ１３７１乃至Ｓ１３７３，Ｓ１３７５乃至Ｓ１３８０の処理は、図１３４のステップＳ１２５１乃至Ｓ１２５５，Ｓ１２５７乃至Ｓ１２６０の処理と同様であるので、その説明は省略する。
　さらに、図１４１のステップＳ１３９２乃至Ｓ１３９６の処理は、図１３５のステップＳ１２７２乃至Ｓ１２７６の処理と同様であるので、その説明は省略する。
　すなわち、ステップＳ１３７１乃至Ｓ１３７３（図１４０）の処理により、画像が撮像され、定期異常診断が実行され、フレームスタートが送信されると、ステップＳ１３７４において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの埋込データを送信する。
　一方、アプリケーションプロセッサ１２１２においては、ステップＳ１３９１（図１４１）において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１５５２は、イメージセンサ１２１１より送信されてきた埋込データのパケットフッタを受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　そして、ステップＳ１３９１において、イメージセンサ１２１１より送信されてきた埋込データのパケットフッタを受信したと判定された場合、処理は、ステップＳ１３９２に進む。
　ステップＳ１３９２において、拡張モード対応CSI-2受信回路１５５２は、低速コマンド送信により、読み出し命令をイメージセンサ１２１１に送信する。
　イメージセンサ１２１１においては、ステップＳ１３７５，Ｓ１３７６（図１４０）の処理により、読み出し命令に応じて、定期異常診断の診断結果に応じた特異メッセージを含む読み出し応答が、画像データを送信する高速データ送信によりアプリケーションプロセッサ１２１２に送信される。
　以上の処理により、消費電力の最大値に対して影響を与えることなく、画像データを送信する前に、イメージセンサ１２１１の動作異常の可能性または動作異常の発生を、アプリケーションプロセッサ１２１２に迅速に通知することが可能となり、特異メッセージに応じた迅速な対応が可能になる。
　＜撮像送信処理（その７）＞
　以上においては、読み出し命令送信および読み出し応答送信は、埋込データ送信後のラインブランキング期間内に実施される例について説明してきたが、画像データ送信後のラインブランキング期間内に実施されてもよい。
　この場合、画像データのライン毎にイメージセンサ１２１１において定期異常診断が実施されて、特異メッセージが送信されるので、消費電力の最大値へ影響を与えることなく、各行の画像データに対応する特異メッセージを迅速にアプリケーションプロセッサ１２１２に通知することが可能となる。
　ここで、図１４２，図１４３のフローチャートを参照して、読み出し命令送信および読み出し応答送信を、画像データ送信後のラインブランキング期間内に実施されるようにした撮像送信処理について説明する。
　図１４２のフローチャートは、イメージセンサ１２１１の処理を表しており、図１４３のフローチャートは、アプリケーションプロセッサ１２１２の処理を表している。
　また、図１４２のステップＳ１４１１乃至Ｓ１４１３，Ｓ１４１６，Ｓ１４１７，Ｓ１４１９，Ｓ１４２０の処理は、図１４０のステップＳ１３７１，Ｓ１３７３乃至Ｓ１３７６，Ｓ１３７９，Ｓ１３８０の処理と同様であるので、その説明は省略する。
　さらに、図１４３のステップＳ１４３２乃至Ｓ１４３６の処理は、図１４１のステップ１３９２乃至Ｓ１３９６の処理と同様であるので、その説明は省略する。
　すなわち、ステップＳ１４１１乃至Ｓ１４１３（図１４２）の処理により、画像が撮像され、フレームスタートが送信され、埋込データが送信されると、ステップＳ１４１４において、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの画像データを送信する。
　ステップＳ１４１５において、イメージセンサ１２１１は、定期異常診断を実行する。
　一方、アプリケーションプロセッサ１２１２においては、ステップＳ１４３１（図１４３）において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１５５２は、イメージセンサ１２１１より送信されてきた画像データのパケットフッタを受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　そして、ステップＳ１４３１において、イメージセンサ１２１１より送信されてきた画像データのパケットフッタを受信したと判定された場合、処理は、ステップＳ１４３２に進む。
　ステップＳ１４３２において、拡張モード対応CSI-2受信回路１５５２は、低速コマンド送信により、読み出し命令をイメージセンサ１２１１に送信する。
　イメージセンサ１２１１においては、ステップＳ１４１６，Ｓ１４１７（図１４２）の処理により、読み出し命令に応じて、定期異常診断の診断結果に応じた特異メッセージを含む読み出し応答が、画像データを送信する高速データ送信によりアプリケーションプロセッサ１２１２に送信される。
　さらに、ステップＳ１４１８において、拡張モード対応CSI-2送信回路１５０４は、１フレーム分の画像データの送信が完了したか否かを判定する。
　ステップＳ１４１８において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了していないと判定した場合、処理はステップＳ１４１４に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１４１８において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了したと判定した場合、処理はステップＳ１４１９に進む。
　以上の処理により、画像データのライン毎にイメージセンサ１２１１が定期異常診断を実施して、特異メッセージを送信するので、消費電力の最大値へ影響を与えることなく、各行の画像データに対応する特異メッセージを迅速にアプリケーションプロセッサ１２１２に通知することが可能となる。
　結果として、アプリケーションプロセッサ１２１２は、特異メッセージに応じた迅速な対応が可能となる。
　＜撮像送信処理（その８）＞
　以上においては、読み出し命令送信および読み出し応答送信が画像データ送信後のラインブランキング期間内に実施される例について説明してきたが、割り込み機能を用いて特異メッセージが送信されるようにしてもよい。
　割り込み機能を用いる場合、イメージセンサ１２１１は、アプリケーションプロセッサ１２１２と容易に同期できるので、イメージセンサ１２１１が決めるタイミングで割り込み実行することによって、イメージセンサ１２１１が決めるタイミングで特異メッセージを送信することが可能となる。
　なお、イメージセンサ１２１１は、帯域内割込みによって読み出し命令をトリガし、それに応じて読み出し応答を送信してもよいし、帯域内割込みによって読み出し命令を省略して読み出し応答を送信してもよい。
　ここで、図１４４，図１４５のフローチャートを参照して、割り込み機能を用いて特異メッセージが送信されるようにした撮像送信処理について説明する。
　図１４４のフローチャートは、イメージセンサ１２１１の処理を表しており、図１４５のフローチャートは、アプリケーションプロセッサ１２１２の処理を表している。
　また、図１４４のステップＳ１４５１乃至Ｓ１４５３，Ｓ１４５５，Ｓ１４５６，Ｓ１４５８乃至Ｓ１４６１の処理は、図１４０のステップＳ１３７１乃至Ｓ１３７３，Ｓ１３７５乃至Ｓ１３８０の処理と同様であるので、その説明は省略する。
　さらに、図１４５のステップＳ１４７２乃至Ｓ１４７６の処理は、図１４１のステップ１３９２乃至Ｓ１３９６の処理と同様であるので、その説明は省略する。
　すなわち、ステップＳ１４５１乃至Ｓ１４５３（図１４４）の処理により、イメージセンサ１２１１においては、画像が撮像され、定期異常診断が実行され、フレームスタートが送信される。
　ステップＳ１４５４において、拡張モード対応CSI-2送信回路１５０４は、割り込み実行の開始をアプリケーションプロセッサ１２１２に通知する。
　一方、アプリケーションプロセッサ１２１２においては、ステップＳ１４７１（図１４５）において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１５５２は、イメージセンサ１２１１より送信されてくる割り込み実行の開始を示す通知を受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　そして、ステップＳ１４７１において、イメージセンサ１２１１より送信されてくる割り込み実行の開始を示す通知を受信したと判定された場合、処理は、ステップＳ１４７２に進む。
　ステップＳ１４３２において、拡張モード対応CSI-2受信回路１５５２は、低速コマンド送信により、読み出し命令をイメージセンサ１２１１に送信する。
　イメージセンサ１２１１においては、ステップＳ１４５５，Ｓ１４５６（図１４４）の処理により、読み出し命令に応じて、定期異常診断の診断結果に応じた特異メッセージを含む読み出し応答が、画像データを送信する高速データ送信によりアプリケーションプロセッサ１２１２に送信される。
　さらに、ステップＳ１４５７において、拡張モード対応CSI-2送信回路１５０４は、埋込データを送信する。
　以上の処理により、割り込み機能を用いることが可能となるので、イメージセンサ１２１１が決めるタイミングで割り込み実行することによって、イメージセンサ１２１１が決めるタイミングで特異メッセージをアプリケーションプロセッサ１２１２に送信することが可能となる。
　なお、イメージセンサ１２１１は、帯域内割込みによって読み出し命令をトリガし、それに応じて読み出し応答を送信してもよいし、帯域内割込みによって読み出し命令を省略して読み出し応答を送信してもよい。
　＜撮像送信処理（その９）＞
　以上においては、割り込み機能を用いて特異メッセージが送信される例について説明してきたが、画像データ送信のバーチャルチャネルとは異なるバーチャルチャネルのデータ内（例えば、埋込データ内）に特異メッセージを格納して送信されるようにしてもよい。
　画像データ送信とは異なるバーチャルチャネルのデータ内に特異メッセージを格納して送信することにより、画像データ送信のバーチャルチャネルの埋込データ内に特異メッセージを格納する余地がない場合でも特異メッセージを送信することが可能となる。
　なお、定期異常診断がフレームブランキング期間内に実行されることで、送信と同時には定期異常診断がなされないようにできるので、消費電力の最大値に対して影響を与えない。また、定期異常診断は、フレームブランキング期間外に実行されるようにしてもよい。
　これにより、画像データを送信する前に、イメージセンサ１２１１の動作異常の可能性、また動作異常の発生を、アプリケーションプロセッサ１２１２に迅速に通知することが可能となる。
　ここで、図１４６のフローチャートを参照して、イメージセンサ１２１１による画像データ送信とは異なるバーチャルチャネルのデータ内に特異メッセージを格納して送信するようにした撮像送信処理について説明する。
　なお、ここでは、第１のバーチャルチャネル（VC1）において、画像データが送信され、第２のバーチャルチャネル（VC2）において、特異メッセージを含む埋込データが送信される処理について説明する。
　ステップＳ１４９１において、画素１５０１が撮像を開始し、画素１５０１から出力される画像データが、AD変換器１５０２および画像処理部１５０３を介して拡張モード対応CSI-2送信回路１５０４に供給される。
　ステップＳ１４９２において、イメージセンサ１２１１は、定期異常診断を実行する。
　ステップＳ１４９３において、拡張モード対応CSI-2送信回路１５０４は、第１のバーチャルチャネルのフレームスタートを送信する。
　ステップＳ１４９４において、拡張モード対応CSI-2送信回路１５０４は、第２のバーチャルチャネルのフレームスタートを送信する。
　ステップＳ１４９５において、拡張モード対応CSI-2送信回路１５０４は、第１のバーチャルチャネルの埋め込みデータを送信する。
　ステップＳ１４９６において、拡張モード対応CSI-2送信回路１５０４は、第２のバーチャルチャネルの埋め込みデータを送信する。このとき、拡張モード対応CSI-2送信回路１５０４は、定期異常診断の診断結果に対応する特異メッセージを含めた第２のバーチャルチャネルの埋め込みデータを送信する。
　ステップＳ１４９７おいて、拡張モード対応CSI-2送信回路１５０４は、第１のバーチャルチャネルの画像データを送信する。
　ステップＳ１４９８において、拡張モード対応CSI-2送信回路１５０４は、１フレーム分の画像データの送信が完了したか否かを判定する。
　ステップＳ１４９８において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了していないと判定した場合、処理はステップＳ１４９７に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１４９８において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了したと判定した場合、処理はステップＳ１４９９に進む。
　ステップＳ１４９９において、拡張モード対応CSI-2送信回路１５０４は、第２のバーチャルチャネルのユーザ定義データを送信する。
　ステップＳ１５００において、拡張モード対応CSI-2送信回路１５０４は、第１のバーチャルチャネルのフレームエンドを送信する。
　ステップＳ１５０１において、拡張モード対応CSI-2送信回路１５０４は、第２のバーチャルチャネルのフレームエンドを送信する。
　ステップＳ１５０２において、拡張モード対応CSI-2送信回路１５０４は、高速データ送信の終了命令を受信したか否かを判定する。
　ステップＳ１５０２において、拡張モード対応CSI-2送信回路１５０４が、高速データ送信の終了命令を受信していないと判定した場合、処理はステップＳ１４９１に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１５０２において、拡張モード対応CSI-2送信回路１５０４が、高速データ送信の終了命令を受信したと判定した場合、処理は終了される。
　以上の処理により、画像データ送信のバーチャルチャネルの埋込データ内に特異メッセージを格納する余地がない場合でも特異メッセージを送信することが可能となる。
　＜撮像送信処理（その１０）＞
　以上においては、画像データ送信のバーチャルチャネルとは異なるバーチャルチャネルのデータ内（例えば、埋込データ内）に特異メッセージを格納して送信される例について説明してきたが、画像データ送信のバーチャルチャネルとは異なるバーチャルチャネルの、非画像データの少なくとも一部内に格納されて送信されてもよい。
　非画像データは、例えば、パケットデータ（例えば、Generic Short Packet Data Types、Generic Long Packet Data Types）、ユーザ定義データ（User Defined Byte-based Data）またはリザーブド領域データ（Reserved for future use）である。
　特異メッセージが、画像データ送信のバーチャルチャネルとは異なるバーチャルチャネルの、非画像データの少なくとも一部内に格納される場合、イメージセンサ１２１１は、画像データのラインごとに特異メッセージを送信するので、各行の画像データに対応する特異メッセージを迅速に送信することが可能となる。
　これにより、特異メッセージを受信するアプリケーションプロセッサ１２１２は、特異メッセージに応じた迅速な対応が可能になる。
　定期異常診断が画像データ送信の前のラインブランキング期間内に実行されることにより、送信と同時には定期異常診断がなされないため、消費電力の最大値へ影響を与えない。また、定期異常診断は、ラインブランキング期間外に実行されるようにしてもよい。
　ここで、図１４７のフローチャートを参照して、画像データ送信のバーチャルチャネルとは異なるバーチャルチャネルの、非画像データの少なくとも一部内に格納されて送信されるようにした撮像送信処理について説明する。
　なお、ここでは、第１のバーチャルチャネル（VC1）において、画像データが送信され、第２のバーチャルチャネル（VC2）において、特異メッセージを含むユーザ定義データが送信される処理について説明する。
　また、図１４７のフローチャートのステップＳ１５２１乃至Ｓ１５２５，ステップＳ１５３０乃至Ｓ１５３２の処理は、図１４６のフローチャートのステップＳ１４９１，Ｓ１４９３乃至Ｓ１４９６，Ｓ１５００乃至Ｓ１５０２の処理と同様であるので、その説明は省略する。ただし、ステップＳ１５２５の処理は、定期異常診断の診断結果を含まない点でステップＳ１４９６の処理とは異なる。
　すなわち、ステップＳ１５２１乃至Ｓ１５２５の処理により、撮像が開始され、第１のバーチャルチャネルと第２のバーチャルチャネルのそれぞれのフレームスタートと埋込データが送信されると、処理は、ステップＳ１５２６に進む。
　ステップＳ１５２６において、イメージセンサ１２１１は、定期異常診断を実行する。
　ステップＳ１５２７おいて、拡張モード対応CSI-2送信回路１５０４は、第１のバーチャルチャネルの画像データを送信する。
　ステップＳ１５２８において、拡張モード対応CSI-2送信回路１５０４は、第２のバーチャルチャネルのユーザ定義データを送信する。このとき、拡張モード対応CSI-2送信回路１５０４は、定期異常診断の診断結果に対応する特異メッセージを含む第２のバーチャルチャネルのユーザ定義データを送信する。
　ステップＳ１５２９において、拡張モード対応CSI-2送信回路１５０４は、１フレーム分の画像データの送信が完了したか否かを判定する。
　ステップＳ１５２９において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了していないと判定した場合、処理はステップＳ１５２６に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１５２９において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了したと判定した場合、処理はステップＳ１５３０に進む。
　そして、ステップＳ１５３０，Ｓ１５３１において、第１のバーチャルチャネルと第１のバーチャルチャネルのフレームエンドが送信される。
　以上の処理により、画像データのラインごとに特異メッセージをイメージセンサが送信されるので、各行の画像データに対応する特異メッセージを迅速に送信することが可能となる。
　結果として、特異メッセージを受信するアプリケーションプロセッサ１２１２は、特異メッセージに応じた迅速な対応が可能になる。
　また、以上においては、特異メッセージを含むユーザ定義データが送信される例について説明してきたが、特異メッセージを含む非画像データであれば、ユーザ定義データでなくてもよく、例えば、特異メッセージを含むパケットデータやリザーブド領域データでもよい。
　＜撮像送信処理（その１１）＞
　以上においては、画像データ送信のバーチャルチャネルとは異なるバーチャルチャネルの、非画像データの少なくとも一部内に特異メッセージが格納されて送信される例について説明してきたが、画像データ内に格納されて送信されてもよい。
　特異メッセージが画像データ内に格納されて送信される場合、画像データのライン毎にイメージセンサ１２１１が特異メッセージを送信するので、各行の画像データに対応する特異メッセージを迅速に送信することが可能となる。
　これにより、特異メッセージを受信するアプリケーションプロセッサ１２１２は、特異メッセージに応じた迅速な対応が可能になる。
　また、定期異常診断がラインブランキング期間内に実行されることにより、送信と同時には定期異常診断されないので、消費電力の最大値へ影響を与えない。
　さらに、定期異常診断は、ラインブランキング期間外に実行されるようにしてもよい。
　また、特異メッセージが画像データ内へ格納される場合、可視電子透かしメッセージまたは不可視電子透かしメッセージが重畳して格納されてもよい。
　例えば、可視電子透かしを用い、特異メッセージとして所定メッセージ（例えば、警告表示）が格納されてもよい。また、可視電子透かしを用い、イメージセンサ１２１１が高速データ送信を終了するまでのカウントダウンやカウントアップを示すカウントメッセージ（所定メッセージ）が格納されてもよい。
　これらは、人が認識できる表現（例えば、固定パターン）であってもよいし、人が認識できない表現（例えば、ランダムパターン）であってもよい。また、画像変化が微小であるために肉眼で視認しにくい、不可視電子透かしを用いて格納されてもよい。
　ここで、図１４８のフローチャートを参照して、特異メッセージが画像データ内に格納されて送信されるようにした撮像送信処理について説明する。
　なお、図１４８のフローチャートのステップＳ１５５１，Ｓ１５５２，ステップＳ１５５７，Ｓ１５５８の処理は、図１３１のフローチャートのステップＳ１１９１，Ｓ１１９３，Ｓ１１９７，Ｓ１１９８の処理と同様であるので、その説明は省略する。
　すなわち、ステップＳ１５５１，Ｓ１５５２の処理により、撮像が開始され、フレームスタートが送信され、ステップＳ１５５３の処理により、埋込データが送信されると、処理は、ステップＳ１５５４に進む。
　ステップＳ１５５４において、イメージセンサ１２１１は、定期異常診断を実行する。
　ステップＳ１５５５おいて、拡張モード対応CSI-2送信回路１５０４は、バーチャルチャネルの画像データを送信する。このとき、拡張モード対応CSI-2送信回路１５０４は、定期異常診断の診断結果に対応する特異メッセージを含めて、バーチャルチャネルの画像データを送信する。
　ステップＳ１５５６において、拡張モード対応CSI-2送信回路１５０４は、１フレーム分の画像データの送信が完了したか否かを判定する。
　ステップＳ１５５６において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了していないと判定した場合、処理はステップＳ１５５４に戻り、以下、同様の処理が繰り返して行われる。一方、ステップＳ１５５６において、拡張モード対応CSI-2送信回路１５０４が、１フレーム分の画像データの送信が完了したと判定した場合、処理はステップＳ１５５７に進む。
　そして、ステップＳ１５５７において、バーチャルチャネルのフレームエンドが送信される。
　以上の処理により、画像データのライン毎にイメージセンサ１２１１が特異メッセージを送信することが可能となり、各行の画像データに対応する特異メッセージをアプリケーションプロセッサ１２１２に対して迅速に送信することが可能となる。
　これにより、特異メッセージを受信するアプリケーションプロセッサ１２１２は、特異メッセージに応じた迅速な対応が可能になる。
　なお、以上の説明では、撮像開始を明記しているが、撮像終了について明記していない。これは撮像方式がグローバルシャッタ方式なのかローリングシャッタ方式なのか等によって異なるためである。
　例えば、グローバルシャッタ方式であれば、全画素を一斉に撮像できるので、次処理の前までに撮像終了してもよいし、フレーム内最初の画像データ送信の前までに撮像終了してもよい。
　一方、ローリングシャッタ方式であれば、画素の各行で実行される撮像および高速データ送信の少なくとも一部が重複して実行（並列実行）されてもよいため、フレーム内最後の画像データ送信の前までに撮像終了すればよい。
　また、撮像開始のタイミングは一例であり、例えば、フレーム内最初の画像データ送信の前のタイミングまで遅らせて実行されてもよい。
　さらに、定期異常診断のタイミングも一例であり、例えば、特異メッセージ送信の前のタイミングまで遅らせて実行されてもよい。
　＜メッセージカウント値について＞
　メッセージカウンタ１５１３は、HD（Humming Distance）≧1カウント（バイナリコード）とHD=1カウント（グレイコード）との何れかをインクリメントまたはデクリメントすることでメッセージカウンタ（メッセージカウント値）を生成する。
　なお、図１４９においては、図中の左側にHD（Humming Distance：ハミング距離）≧1のバイナリコードからなるメッセージカウント値の例が示されており、図中の右側にHD=1のグレイコードからなるメッセージカウント値の例が示されており、いずれも図中の下方向に向かってインクリメントされている。
　特に、メッセージカウンタ（メッセージカウント値）がグレイコードである場合、インクリメントまたはデクリメントに伴うハミング距離が一定になるので、電力観測攻撃や電磁観測攻撃に対する耐性を向上させることができる。
　メッセージカウント値は、カウント方式として、第１コード方式と第２コード方式と（例えば、バイナリコード方式とグレイコード方式と）が切り替えられてもよい。
　また、メッセージカウント値のカウント方式が必要に応じて切り替えられる場合、送信されるデータ量自体を変えることなく、イメージセンサ１２１１からアプリケーションプロセッサ１２１２に対して付加情報を伝達させるようにすることができる。
　例えば、イメージセンサ１２１１内において異常が検出される場合、メッセージカウント値のカウント方式が切り替えられてもよく、カウント方式に応じてイメージセンサ１２１１からアプリケーションプロセッサ１２１２に異常情報（例えば、異常の有無）を伝達することが可能となる。
　特に、バイナリコードとグレイコードとが切り替えられる場合、メッセージカウンタのインクリメントまたはデクリメントを維持しながら、付加情報を伝達することが可能となる。
　イメージセンサ１２１１が、バイナリコードとグレイコードとを切り替える場合、カウント切り替えなのかメッセージ送受信の不具合なのかをアプリケーションプロセッサ１２１２が判別できるようにするために、コード周期（左記は4ビットでコード周期が16カウントの例）を考慮したタイミングで切り替えることが望ましいが、その限りではない。
　イメージセンサ１２１１は、互いに関連性ある第１カウンタと第２カウンタとを備える場合、メッセージカウンタの不具合または改竄の有無を検証することが可能になる。
　例えば、インクリメントする第１カウンタとデクリメントする第２カウンタとの演算（例えば、加算）の結果からカウンタの不具合や改竄の有無を検証してもよい。
　すなわち、例えば、バイナリコードをインクリメントする第１カウンタとデクリメントする第２カウンタとが用いられる場合、図１５０で示されるように、それぞれの加算結果は、不具合や改竄がない限り、常に「1111」になる。このため、それぞれの加算結果が、「1111」となる場合、第１カウンタと第２カウンタとは正常値であるので、加算結果が「1111」からなる正常値であるか否かにより、不具合や改竄の有無を検証することができる。
　また、カウント方向が同じ第１カウンタと第２カウンタとの演算（例えば、減算）の結果からカウンタの不具合や改竄の有無を検証してもよい。
　すなわち、例えば、グレイコードをインクリメントする第１カウンタとデクリメントする第２カウンタとの場合、図１５１で示されるように、それぞれの減算結果は、不具合や改竄がない限り、常に「0000」になる。このため、それぞれの減算結果が、「0000」となる場合、第１カウンタと第２カウンタとは正常値であるので、減算結果が「0000」からなる正常値であるか否かにより、不具合や改竄の有無を検証することができる。
　＜メッセージカウント処理＞
　次に、図１５２のフローチャートを参照して、メッセージカウント処理について説明する。
　ステップＳ１５７１において、メッセージカウンタ１５１３は、第１カウント値および第２カウント値を初期化する。
　ステップＳ１５７２において、拡張モード対応CSI-2送信回路１５０４は、拡張パケットヘッダを送信するか否かを判定し、拡張パケットヘッダを送信すると判定されるまで処理を待機する。
　ステップＳ１５７２において、拡張パケットヘッダを送信すると判定された場合、処理は、ステップＳ１５７３に進む。
　ステップＳ１５７３において、拡張モード対応CSI-2送信回路１５０４は、メッセージカウンタ１５１３からメッセージカウント値として第１カウント値を取得し、拡張パケットヘッダに格納する。
　ステップＳ１５７４において、拡張モード対応CSI-2送信回路１５０４は、拡張パケットヘッダをアプリケーションプロセッサ１２１２に送信する。
　ステップＳ１５７５において、メッセージカウンタ１５１３は、第１カウント値が最大値であるか否かを判定する。
　ステップＳ１５７５において、第１カウント値が最大値であると判定された場合、処理は、ステップＳ１５７１に戻り、第１カウント値および第２カウント値が初期化される。
　また、ステップＳ１５７５において、第１カウント値が最大値ではないと判定された場合、処理は、ステップＳ１５７６に進む。
　ステップＳ１５７６において、メッセージカウンタ１５１３は、第１メッセージカウンタの第１カウント値を更新する（インクリメントまたはデクリメントする）。
　ステップＳ１５７７において、メッセージカウンタ１５１３は、第２メッセージカウンタの第２カウント値を更新する（インクリメントまたはデクリメントする）。
　ステップＳ１５７８において、メッセージカウンタ１５１３は、第１カウント値と第２カウント値とを演算する（加算または減算する）。
　ステップＳ１５７９において、メッセージカウンタ１５１３は、演算結果が正常値であるか否かを判定する。
　ステップＳ１５７９において、演算結果が正常値であると判定された場合、処理は、ステップＳ１５８０に進む。
　ステップＳ１５８０において、メッセージカウンタ１５１３は、第１カウント値と第２カウント値とが正常であると判定する。
　ステップＳ１５７９において、演算結果が正常値ではないと判定された場合、処理は、ステップＳ１５８１に進む。
　ステップＳ１５８１において、メッセージカウンタ１５１３は、第１カウント値と第２カウント値との少なくともいずれかが異常であると判定する。
　以上の処理により、メッセージカウンタのカウント値に対する不具合や改竄に対する耐性を向上させることが可能となる。
　なお、イメージセンサ１２１１は、正常と判断される場合は正常メッセージを、異常と判断される場合は異常メッセージを、それぞれ特異メッセージとして送信してもよい。また、メッセージカウント値は、異常メッセージなどの特異メッセージとして流用されてもよい。
　一方、特異メッセージは、フレームエンド外（例えば、フレームスタート内、埋込データ内、画像データ内）の拡張パケットフッタ内に格納されてもよい。また、特異メッセージを含むデータの暗号に基づく完全性演算値は、フレームエンド内の拡張パケットフッタ内に格納されてもよい。さらに、特異メッセージを含むデータの暗号に基づく完全性演算は、拡張パケットフッタ内ではなく、埋込データ内のパケットデータ内に格納されても
よい。
　以上のように、イメージセンサ１２１１からアプリケーションプロセッサ１２１２に対して特異メッセージや付加情報が伝達される例を用いて説明したが、同様な考え方に従いアプリケーションプロセッサ１２１２からイメージセンサ１２１１またはディスプレイ１２１３に対して特異メッセージや付加情報が伝達されてもよい。
　＜異常を識別する情報の格納について＞
　拡張パケットヘッダ内または拡張パケットフッタ内には、例えば、Fatal warning（重大な異常を検出）、Sensor-internal warning（センサ内部に起因する異常を検出）、Sensor-external warning（センサ外部に起因する異常を検出）、Power-source warning（電源に起因する異常を検出）、Clock-source warning（クロック源に起因する異常を検出）、The others warning（その他に起因する異常を検出）、Physical warning（物理異常を検出）、Logical warning（論理異常を検出）、Power warning（電力異常を検出）、Voltage warning（電圧異常を検出）、Current warning（電流異常を検出）、Electromagnetic warning（電磁異常を検出）、Clock warning（クロック異常を検出）、Thermal warning（温度異常を検出）、Channel warning（伝送路異常を検出）、Message warning（メッセージ異常を検出）、Attack warning（攻撃を検出）、Tamper warning（例えば、侵害を検出）、Blind warning（例えば、妨害を検出）、Saturation warning（例えば、妨害を検出）、Fake warning（例えば、妨害を検出）、Foreign object warning（例えば、障害を検出）、Probe warning（例えば、侵害または障害を検出）、DOS warning（例えば、メッセージカウント異常を検出）、などの何れかを識別できるように定義されるWarning Descriptor（特異メッセージ）が格納されてもよい。
　Warning Descriptor（特異メッセージ）は、ベンダ固有領域（Vendor specific）、ユーザ定義領域（User Defined）またはリザーブド領域（Reserved for future use）の少なくとも一部内に格納されてもよい。
　また、Warning Descriptor（特異メッセージ）内の何れかの項目は、拡張パケットヘッダ（例えば、Security Descriptor）内または拡張パケットフッタ（例えば、ePF1）内、埋込データ内、および読み出し応答内などの何れかに定義されてもよい。
　なお、図１５３は、図５８の拡張パケットヘッダePH2におけるリザーブド領域（Reserved）にWarning Descriptorが設定されるときの拡張パケットヘッダePH2の構成例が示されている。
　また、図１５４においては、Warning Descriptor（特異メッセージ）の各ビットを用いた識別情報の記述例が示されている。
　＜特異メッセージの分離＞
　特異メッセージの送信は、第１特異メッセージの送信と第２特異メッセージの送信とに分離されてもよい。
　拡張パケットヘッダは、画像データなどのライン（行）の高速データ送信毎に送信されるため、ビット幅が短いことが望ましいが、即時性が高いので、例えば、第１特異メッセージとして警告速報（例えば、Physical attack detection）や警告情報の一部が割り当てられて格納されてもよい。
　一方、例えば、第２特異メッセージに警告情報の詳細を示す情報（警告詳細）が割り当てられて、拡張パケットヘッダ外に格納されて送信されるようにする。
　図１５５は、拡張パケットヘッダに、第１特異メッセージとして警告速報（例えば、Physical attack detection）が設定される例を示している。
　＜特異メッセージを分離して送信するときの送信処理＞
　次に、図１５６，図１５７のフローチャートを参照して、特異メッセージを分離して送信するときの送信処理について説明する。
　なお、図１５６のフローチャートは、イメージセンサ１２１１の処理を表しており、図１５７のフローチャートは、アプリケーションプロセッサ１２１２の処理を表している。
　ステップＳ１５９１（図１５６）において、イメージセンサ１２１１は、異常診断を実行する。
　ステップＳ１５９２において、拡張モード対応CSI-2送信回路１５０４が、第１特異メッセージである警告速報を含む拡張パケットヘッダを送信する。
　ステップＳ１５９３において、拡張モード対応CSI-2送信回路１５０４が、第２特異メッセージである警告詳細を含む拡張パケットヘッダ外の、例えば、埋込データに含めて送信する。
　一方、ステップＳ１６１１において、アプリケーションプロセッサ１２１２は、警告速報を含む拡張パケットヘッダを受信したか否かを判定し、警告速報を含む拡張パケットヘッダを受信するまで、同様の処理を繰り返す。
　ステップＳ１６１１において、警告速報を含む拡張パケットヘッダを受信したと判定された場合、処理は、ステップＳ１６１２に進む。
　ステップＳ１６１２において、アプリケーションプロセッサ１２１２は、警告速報に基づいて、異常時処理を開始する。
　ステップＳ１６１３において、アプリケーションプロセッサ１２１２は、警告詳細を含む埋込データなどの拡張パケットヘッダを受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　そして、ステップＳ１６１３において、警告詳細を含む埋込データなどの拡張パケットヘッダを受信したと判定された場合、処理は、ステップＳ１６１４に進む。
　ステップＳ１６１４において、アプリケーションプロセッサ１２１２は、警告詳細の情報を、異常時処理に反映させる。
　以上の処理により、異常診断により異常が検出される場合に、即時性の高い警告速報（例えば、Physical attack detection）を迅速にアプリケーションプロセッサ１２１２に送信することが可能となり、異常時処理を迅速に開始することが可能となる。
　＜特異メッセージを分離して送信するときの送信処理の変形例＞
　以上においては、第１特異メッセージとして警告速報が送信される例について説明してきたが、さらに、警告速報が送信された後、警告詳細の読み出し命令を送信して、イメージセンサ１２１１から読み出し応答として警告詳細が送信されるようにしてもよい。
　次に、図１５８のフローチャートを参照して、警告速報が送信された後、警告詳細の読み出し命令を送信する場合の特異メッセージを分離して送信するときの送信処理について説明する。
　なお、図１５８のフローチャートにおけるステップＳ１６３１，Ｓ１６３２，Ｓ１６３４，Ｓ１６３５の処理は、図１５７のフローチャートにおけるステップＳ１６１１乃至Ｓ１６１３の処理と同様であるので、その説明は省略する。
　すなわち、ステップＳ１６３１，Ｓ１６３２の処理により、警告速報が受信されて、異常時処理が開始されると、ステップＳ１６３３において、アプリケーションプロセッサ１２１２が読み出し命令を送信する。
　これに応じて、イメージセンサ１２１１は、読み出し命令に応じて読み出し応答をアプリケーションプロセッサ１２１２に送信する。
　そして、ステップＳ１６３４，Ｓ１６３５の処理により、警告詳細が受信されて、異常時処理に反映させる。
　以上の処理により、異常診断により異常が検出される場合に、即時性の高い警告速報（例えば、Physical attack detection）を迅速にアプリケーションプロセッサ１２１２に送信することが可能となり、さらに、警告詳細を迅速に異常時処理に反映させることが可能となる。
　＜Security Descriptor＞
　拡張パケットヘッダ内または拡張パケットフッタ内には、パケットデータ（ペイロード）の暗号化の有無や、拡張パケットフッタ内のハッシュ値、メッセージ認証コードまたはデジタル署名の有無や、拡張パケットフッタ内のハッシュ値、メッセージ認証コードまたはデジタル署名のアルゴリズム種類などの何れかが定義されるSecurity Descriptor（例えば、Service Descriptorと呼称されてもよい）が格納されてもよい。
　また、イメージセンサ１２１１は、このSecurity Descriptorを用いて、イメージセンサ１２１１内外の異常の有無、イメージセンサ１２１１に対する妨害または攻撃の有無、などの何れかの特異メッセージをアプリケーションプロセッサ１２１２に通知してもよい。
　メッセージ認証コード（MAC: Message Authentication Code）としては、GMAC（GaloisMAC）、CMAC（Cipher-based MAC）、HMAC（Hash-based MAC）、などの何れかが用いられてもよい。例えば、AES（Advanced Encryption Standard）またはSHA（Secure Hash Algorithm）が適用された、AES-GMAC、AES-CMAC、SHA2-HMAC、SHA3-HMACなどの何れかが用いられてもよい。
　図１５９は、図１５３におけるSecurity Descriptorに、イメージセンサ１２１１内外の異常の有無、およびイメージセンサ１２１１に対する妨害または攻撃の有無などの何れかの特異メッセージが設定される例が示されている。
　＜推進装置に実装される例＞
　イメージセンサ１２１１およびアプリケーションプロセッサ１２１２は、所望の推進装置に搭載される構成とすることができる。
　推進装置は、例えば、推進（可動、走行、歩行、飛行などの何れか）することが可能な車両、ロボット、ドローンなどの何れかであってもよく、AI（Artificial Intelligence）機能を搭載して自律推進できる、自律車両、自律ロボット、自律ドローンなどの何れかであってもよい。
　推進装置の推進は、推進装置の使用者によって制御されてもよく、推進装置は使用者に対して必要に応じて指示または警告を通知してもよい。一方、推進装置は、自らの推進を推進装置自身が自動制御するように構成されてもよい。
　図１６０は、上述したイメージセンサ１２１１およびアプリケーションプロセッサ１２１２が搭載される推進装置の制御システムの一例である推進制御システムの概略的な構成例を示すブロック図である。
　推進制御システム１６００は、通信ネットワーク１６０１を介して接続された複数の電子制御ユニットを備える。図１６０に示した例では、推進制御システム１６００は、駆動系制御ユニット１６１５、ボディ系制御ユニット１６１６、外部情報検出ユニット１６１７、内部情報検出ユニット１６１９、及び統合制御ユニット１６１１を備える。また、統合制御ユニット１６１１の機能構成として、マイクロコンピュータ１６３１、音声画像出力部１６３２、及び車載ネットワークＩ／Ｆ（ｉｎｔｅｒｆａｃｅ）１６３３が図示されている。
　駆動系制御ユニット１６１５は、各種プログラムにしたがって推進装置の駆動系に関連する装置の動作を制御する。
　ボディ系制御ユニット１６１６は、各種プログラムにしたがって推進装置に装備された各種装置の動作を制御する。
　外部情報検出ユニット１６１７は、推進制御システム１６００を搭載した推進装置の外部の情報を検出する。例えば、外部情報検出ユニット１６１７には、撮像部１６１８が接続される。外部情報検出ユニット１６１７は、撮像部１６１８に推進装置の外部の画像を撮像させるとともに、撮像された画像を受信する。外部情報検出ユニット１６１７は、受信した画像に基づいて、人、車、障害物、標識又は路面上の文字等の物体検出処理又は距離検出処理を行ってもよい。また、外部情報検出ユニット１６１７は、アプリケーションプロセッサ１２１２に対応する構成であってもよい。
　撮像部１６１８は、イメージセンサ１２１１に対応する構成であり、光を受光し、その光の受光量に応じた電気信号を出力する光センサである。撮像部１６１８は、電気信号を画像として出力することもできるし、測距の情報として出力することもできる。また、撮像部１６１８が受光する光は、可視光であっても良いし、赤外線等の非可視光であっても良い。
　内部情報検出ユニット１６１９は、推進装置の内部の情報を検出する。内部情報検出ユニット１６１９には、推進装置の内部の情報を検出する検出部１６２０が接続されるようにしてもよい。ここで、推進装置の内部の情報は、例えば、推進装置の温度や周辺湿度などの情報である。
　マイクロコンピュータ１６３１は、外部情報検出ユニット１６１７又は内部情報検出ユニット１６１９で取得される推進装置の内外の情報に基づいて、各種の制御目標値を演算し、駆動系制御ユニット１６１５に対して制御指令を出力することができる。また、マイクロコンピュータ１６３１は、アプリケーションプロセッサ１２１２に対応する構成であってもよい。
　また、マイクロコンピュータ１６３１は、外部情報検出ユニット１６１７又は内部情報検出ユニット１６１９で取得される推進装置の周囲の情報に基づいて推進を制御することにより、使用者の操作に拠らずに自律的に走行する自動運転等を目的とした協調制御を行うことができる。
　上述したように、撮像部１６１８はイメージセンサ１２１１に対応する構成であり、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１はアプリケーションプロセッサ１２１２に対応する構成であるので、撮像部１６１８と外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１とは、相互に高速データ通信を実現する。
　さらに、マイクロコンピュータ１６３１は、外部情報検出ユニット１６１７で取得される推進装置の外部の情報に基づいて、ボディ系制御ユニット１６１６に対して制御指令を出力することができる。
　音声画像出力部１６３２は、推進装置の搭乗者又は推進装置の外部に対して、視覚的又は聴覚的に情報を通知することが可能な出力装置へ音声及び画像のうちの少なくとも一方の出力信号を送信する。図１６０の例では、出力装置として、オーディオスピーカ１６１２、表示部１６１３及びインストルメントパネル１６１４が例示されている。表示部１６１３は、例えば、オンボードディスプレイ及びヘッドアップディスプレイの少なくとも一つを含んでいてもよい。
　＜推進制御処理（その１）＞
　推進装置は、図１６０の推進制御システム１６００により、異常メッセージが受信（例えば、1回受信、複数回受信、連続受信）される場合、推進装置の推進状況（例えば、推進装置の推進速度、推進装置周囲の障害物の有無）を調査し、推進状況が安全条件を満たすときには高速データ送信を終了してもよく、推進状況が安全条件を満たさないときには、推進制御を変更（例えば、減速、障害物が少ない位置へ推進装置を誘導）してもよい。
　ここで、図１６１のフローチャートを参照して、推進制御システム１６００による上述した推進制御処理について説明する。
　ステップＳ１６５１において、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、イメージセンサ１２１１に相当する撮像部１６１８より異常が発生していることを示す異常メッセージ（からなる特異メッセージ）を受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　この処理においては、異常メッセージからなる特異メッセージが、１回受信されたか、複数回受信されたか、または、連続受信されたかのいずれかに基づいて、受信したか否かが判定されるようにしてもよい。
　ステップＳ１６５１において、異常メッセージを受信したと判定された場合、処理は、ステップＳ１６５２に進む。
　ステップＳ１６５２において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、推進状況を調査する。より具体的には、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、例えば、推進装置の推進速度や、推進装置周囲の障害物の有無等を推進状況として調査する。
　ステップＳ１６５３において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、推進状況が安全条件を満たすか否かを判定する。すなわち、推進装置の推進速度が所定の速度よりも高いか否か、および、推進装置周囲の障害物が所定の距離内に存在するか否か等により、推進状況が安全条件を満たすか否かが判定される。
　ステップＳ１６５３において、推進状況が安全条件を満たさないと判定された場合、処理は、ステップＳ１６５４に進む。
　ステップＳ１６５４において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、推進状況が安全条件を満たすように、推進の制御を変更し、処理は、ステップＳ１６５２に戻る。
　すなわち、例えば、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、推進状況が安全条件を満たすまで、駆動系制御ユニット１６１５やボディ系制御ユニット１６１６を制御して、例えば、推進装置の推進速度が所定の速度よりも低い速度となるように推進制御を変更したり、推進装置周囲の障害物が所定の距離内に存在しない状態になるように推進制御を変更する処理を繰り返す。
　そして、ステップ１６５３において、推進状況が安全条件を満たすと判定された場合、処理は、ステップＳ１６５５に進む。
　ステップＳ１６５５において、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、イメージセンサ１２１１に相当する撮像部１６１８との高速データ送信を終了する。
　以上の処理により、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、イメージセンサ１２１１に相当する撮像部１６１８から異常メッセージが供給されても、直ちに高速データ送信を終了するのではなく、推進状況が安全条件を満たすまで推進制御を変更してから、高速データ送信を終了する。
　これにより、イメージセンサ１２１１に相当する撮像部１６１８において異常が発生していることが分かっていても、直ちに高速データ送信が終了されて、推進制御に必要とされる画像データが突然送信されない状態になり、推進制御が致命的な状態に陥るのを防止することが可能となる。
　＜推進制御処理（その２）＞
　推進装置を制御する推進制御システム１６００のアプリケーションプロセッサ１２１２は、画像データを撮像または表示する画像装置（第１情報処理装置または第１プロセッサと通信する第１センサ）と、他データを取得または表示する他データ装置（第２情報処理装置、第１プロセッサまたは第２プロセッサと通信する第２センサ）とを備えてもよい。
　推進制御システム１６００は、画像装置（第１センサ）の状況を調査し、画像装置（第１センサ）に異常が発生してない場合、画像装置の画像データ（第１センサにより取得されるデータ）を優先して推進制御に用いるようにしてもよい。
　また、画像装置（第１センサ）に異常が発生している場合、推進制御システム１６００は、推進装置の使用者に対して小警告を通知するようにしてもよい。そして、他データ装置（第２センサ）の状況を調査し、他データ装置（第２センサ）に異常が発生してない場合、他データ装置の他データ（第２センサにより取得されるデータ）を優先して推進制御に用いるようにしてもよい。
　さらに、他データ装置（第２センサ）に異常が発生している場合、推進制御システム１６００は、推進装置の使用者に対して大警告を通知した上で、推進制御を使用者に移行させるようにして、高速データ送信を終了するようにしてもよい。
　なお、画像装置（第１センサ）と他データ装置（第２センサ）とは同種の構成でも別種の構成でもよい。つまり、画像装置（第１センサ）と他データ装置（第２センサ）とは、可視光センサ、赤外光センサ、紫外光センサ、偏光センサ、測距センサ、ToFセンサ、LiDARセンサなどのイメージセンサや、ミリ波レーダセンサ、超音波レーダセンサ、GPSセンサ、GNSSセンサ、RF測距センサ、RF測位センサなどの何れであってもよい。
　ここで、図１６２のフローチャートを参照して、推進制御システム１６００による上述した推進制御処理について説明する。
　ステップＳ１６７１において、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、画像装置（第１センサ）の状況を調査する。より詳細には、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、例えば、画像装置（第１センサ）における異常診断の診断結果を取得することにより状況を調査する。
　ステップＳ１６７２において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、画像装置（第１センサ）の状況に基づいて、画像装置（第１センサ）に異常が発生しているか否かを判定する。
　ステップＳ１６７２において、画像装置（第１センサ）に異常が発生していないと判定された場合、処理は、ステップＳ１６７３に進む。
　ステップＳ１６７３において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、画像装置（第１センサ）で取得されるデータを優先して使用し、推進装置の推進を制御し、処理は、ステップＳ１６７１に戻り、それ以降の処理が繰り返される。
　すなわち、画像装置（第１センサ）に異常が発生していない限り、画像装置（第１センサ）で取得されるデータを使用して、推進装置の推進が制御される。
　ステップＳ１６７２において、画像装置（第１センサ）に異常が発生していると判定された場合、処理は、ステップＳ１６７４に進む。
　ステップＳ１６７４において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、音声画像出力部１６３２を制御して、オーディオスピーカ１６１２、表示部１６１３、およびインストルメントパネル１６１４の少なくともいずれかを用いて、音声、および画像の少なくともいずれかを用いて、推進装置の使用者に対して、画像装置（第１センサ）に異常が発生していることを示す小警告の情報を提示する。
　ステップＳ１６７５において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、他データ装置（第２センサ）の状況を調査する。より詳細には、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、他データ装置（第２センサ）における異常診断の診断結果を取得することにより、状況を調査する。
　ステップＳ１６７６において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、他データ装置（第２センサ）の状況に基づいて、他データ装置（第２センサ）に異常が発生しているか否かを判定する。
　ステップＳ１６７６において、他データ装置（第２センサ）に異常が発生していないと判定された場合、処理は、ステップＳ１６７７に進む。
　ステップＳ１６７７において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、他データ装置（第２センサ）で取得されるデータを優先して使用し、推進装置の推進を制御し、処理は、ステップＳ１６７１に戻り、それ以降の処理が繰り返される。
　すなわち、画像装置（第１センサ）に異常が発生しても、他データ装置（第２センサ）に異常が発生していない限り、他データ装置（第２センサ）で取得されるデータを使用して、推進装置の推進が制御される。
　ステップＳ１６７６において、他データ装置（第２センサ）に異常が発生していると判定された場合、処理は、ステップＳ１６７８に進む。
　ステップＳ１６７８において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、音声画像出力部１６３２を制御して、オーディオスピーカ１６１２、表示部１６１３、およびインストルメントパネル１６１４の少なくともいずれかを用いて、音声、および画像の少なくともいずれかを用いて、推進装置の使用者に対して、画像装置（第１センサ）および他データ装置（第２センサ）の両方で異常が発生していることを示す大警告の情報を提示する。
　このとき、自律推進が困難な状況になっているので、大警告において、推進装置の推進制御については、使用者で実行するように促す情報が提示されるようにしてもよい。
　ステップＳ１６７９において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、推進装置の推進制御は、図示せぬ操作部等が使用者により操作されることで発生する操作信号に応じたものに移行する。ただし、ステップＳ１６７９の処理以前に、推進装置の推進制御は、図示せぬ操作部等が使用者により操作されることで発生する操作信号に応じたものに移行されてもよい。
　ステップＳ１６８０において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、イメージセンサ１２１１に対応する画像装置（第１センサ）および他データ装置（第２センサ）との高速データ送信を終了して、画像装置（第１センサ）からの画像データや他データ装置（第２センサ）からのデータの入力を受け付けない状態とする。
　以上の処理により、イメージセンサ１２１１に相当する撮像装置（第１センサ）に異常が発生すると、小警告が提示されて異常が発生していることが提示されると共に、他データ装置（第２センサ）で取得されるデータに基づいて推進制御が実行される。
　また、撮像装置（第１センサ）に加えて、他データ装置（第２センサ）にも異常が発生すると、大警告が提示されて異常が発生して、自律的な推進制御が不能な状態になったことが提示されて、使用者による推進制御に切り替えられると共に、高速データ通信が終了される。
　これにより、推進制御に必要とされるデータを取得する一部のセンサ（画像装置（第１センサ））に異常が発生しても、他のセンサ（他データ装置（第２センサ））が取得するデータに基づいた推進制御ができるので、より安全性の高い推進制御を実現することが可能となる。
　また、いずれのセンサにも異常が発生した場合については、使用者に推進制御が移行されることになるので、異常が発生しているセンサにより取得される不確かなデータで推進制御が継続されることがなくなり、安全な推進制御を実現することが可能となる。
　＜推進制御処理（その３）＞
　特異メッセージとして異常メッセージが受信（例えば、1回受信、複数回受信、連続受信）される場合、推進装置の推進を制御する推進制御システム１６００（のアプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）は、推進状況を調査し、高速データ送信を終了できる状態である場合には、高速データ送信を終了してもよい。
　また、高速データ送信を終了できない状態である場合には、推進装置の推進を制御する推進制御システム１６００（のアプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）は、高速データ送信の維持をイメージセンサ１２１１に要求してもよい。
　これにより、高速データ送信は、推進制御システム１６００の撮像部１６１８（イメージセンサ１２１１に相当）ではなく推進装置の推進を制御する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１（のアプリケーションプロセッサ１２１２に相当）によって終了されるので、イメージセンサ１２１１側で一方的に高速データ送信を終了させることで生じる不具合を回避することが可能となる。
　また、イメージセンサ１２１１に相当する撮像部１６１８は、高速データ送信の終了が必要な場合、特異メッセージとして異常メッセージを送信し、異常メッセージが所定条件を満たした後（例えば、所定時間が経過した後、所定回数の異常メッセージが送信された後、カウントダウン機能またはカウントアップ機能を備える異常メッセージが所定値になった後）に、高速データ送信維持が推進装置から要求されてない場合、高速データ送信を終了してもよい。
　一方、高速データ送信維持が推進装置（外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１（のアプリケーションプロセッサ１２１２に相当））から要求されている場合、イメージセンサ１２１１に相当する撮像部１６１８は、高速データ送信の終了予定を延長してもよい。例えば、所定時間や所定回数が延長されてもよく、カウントダウンやカウントアップを示すカウント値が再設定（例えば、初期値へ再設定）されてもよい。
　なお、イメージセンサ１２１１（に相当する撮像部１６１８）は、例えば、何かしらの機能を、更新、初期化、再設定、再起動、全遮断するなどの何れかの高速データ送信不可処理を実行するために、高速データ送信を終了したい場合もあり得るが、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１に対して無断で高速データ送信を終了すると、それに起因して推進装置の事故が発生する可能性がある。
　上述の処理により、イメージセンサ１２１１に相当する撮像部１６１８がアプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１に対して無断で高速データ送信が終了されることがないので、撮像部１６１８からアプリケーションプロセッサ１２１２に対して突然の高速データ送信が終了することに起因する不具合が回避される。
　以上のように、画像装置およびプロセッサは、画像データを用いて推進が直接的または間接的に必要に応じて制御される推進部を備えた推進装置の一部であってもよい。
　次に、図１６３，図１６４のフローチャートを参照して、上述した推進制御処理について説明する。
　なお、図１６３のフローチャートは、推進装置を制御する推進制御システム１６００においてアプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１の処理を表しており、図１６４のフローチャートは、イメージセンサ１２１１に相当する撮像部１６１８の処理を表している。
　ステップＳ１６９１（図１６３）において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、イメージセンサ１２１１に相当する撮像部１６１８より異常メッセージ（からなる特異メッセージ）を受信したか否かを判定し、受信したと判定されるまで、同様の処理を繰り返す。
　ステップＳ１６９１において、異常メッセージを受信したと判定された場合、処理は、ステップＳ１６９２に進む。
　ステップＳ１６９２において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、推進状況を調査する。
　ステップＳ１６９３において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、推進状況に基づいて、高速データ送信を終了できる状態であるか否かを判定する。
　ステップＳ１６９３において、高速データ送信を終了できる状態であるとき、処理は、ステップＳ１６９４に進む。
　ステップＳ１６９４において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、高速データ通信を終了し、イメージセンサ１２１１に相当する撮像部１６１８からの画像データの供給を受け付けない状態にして、処理を終了する。
　一方、ステップＳ１９６３において、高速データ送信を終了できる状態ではないとき、処理は、ステップＳ１６９５に進む。
　ステップＳ１６９５において、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１は、イメージセンサ１２１１に相当する撮像部１６１８に対して、高速データ送信の維持を要求する情報を送信する。
　一方、ステップＳ１７１１において、イメージセンサ１２１１に相当する撮像部１６１８は、異常が発生しており、高速データ送信の終了が必要な状態であるか否かを判定し、必要であると判定されるまで、同様の処理を繰り返す。
　ステップＳ１７１１において、高速データ送信の終了が必要な状態であると判定された場合、処理は、ステップＳ１７１２に進む。
　ステップＳ１７１２において、撮像部１６１８は、異常メッセージからなる特異メッセージをアプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１に送信する。
　ステップＳ１７１３において、撮像部１６１８は、異常メッセージが所定条件を満たしたか否かを判定する。所定条件は、例えば、所定時間が経過したか、所定回数の異常メッセージが送信されたか、カウントダウン機能またはカウントアップ機能を備える異常メッセージが所定値になったか等である。
　ステップＳ１７１３において、異常メッセージが所定条件を満たしたと判定された場合、処理は、ステップＳ１７１４に進む。
　ステップＳ１７１４において、撮像部１６１８は、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１から高速データ送信維持の要求があったか否かを判定する。
　ステップＳ１７１４において、高速データ送信維持の要求があったと判定された場合、処理は、ステップＳ１７１５に進む。
　ステップＳ１７１５において、撮像部１６１８は、高速データ送信の終了予定を延長し、処理は、ステップＳ１７１１に戻る。
　一方、ステップＳ１７１４において、高速データ送信維持の要求がないと判定された場合、処理は、ステップＳ１７１６に進む。
　ステップＳ１７１６において、撮像部１６１８は、高速データ送信を終了し、画像データをアプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１に対して送信しない状態となる。
　以上の処理により、高速データ送信は、撮像部１６１８（イメージセンサ１２１１に相当）ではなく推進装置の推進を制御する推進制御システム１６００の外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１（アプリケーションプロセッサ１２１２に相当）によって終了されるので、イメージセンサ１２１１側で一方的に高速データ送信を終了させることで生じる不具合を回避することが可能となる。
　なお、イメージセンサ１２１１に相当する撮像部１６１８に異常（ネガティブな状況）が発生する可能性あること、または発生したことが警告される例を用いて説明したが、その限りではない。
　例えば、イメージセンサ１２１１に相当する撮像部１６１８にポジティブな状況が発生する可能性あること、または発生したことが伝達されてもよい。また、イメージセンサ１２１１に相当する撮像部１６１８にネガティブでもポジティブでもない状況の変化が発生する可能性があること、または発生したことが伝達されてもよい。
　そこで、上述した異常メッセージは、好転メッセージや変化メッセージなどの、正常時や通常時とは異なるメッセージであってもよい。上述したように、正常時または通常時は、特異メッセージとして正常メッセージまたは通常メッセージが送信されてもよい。また、正常時または通常時とは異なる場合に限り、特異メッセージが送信されてもよい。また、特異メッセージが推進装置内の推進制御システム１６００で用いられる例を用いて説明したが、その限りではなく、特異メッセージは例えばスマートフォンやデジタルカメラなどの何れかのモバイル装置内で用いられてもよい。また、画像データストリームを維持したまま特異メッセージが送信される例を用いて説明したが、その限りではなく、例えば画像データ送信が停止してから特異メッセージが送信されるように構成されてもよい。
　ブロック図やフローチャートなどの何れかの図面を構成する要素のタイミングまたは位置は一例であり、異なるように構成されてもよい。上述した各例で説明した実施の形態は、種々の変形例が存在する。即ち、上述した各例の構成要素は、一部が省略されてもよく、一部または全部が変化していてもよく、一部または全部が変更されていてもよい。
　また、一部が他の構成要素で置き換えられていてもよく、一部または全部に他の構成要素が追加されていてもよい。更には、構成要素の一部または全部が複数に分割されていてもよく、一部または全部が複数に分離されていてもよく、分割または分離された複数の構成要素の少なくとも一部で機能や特徴を異ならせていてもよい。
　さらに、各構成要素の少なくとも一部を移動させて異なる実施の形態としてもよい。更にまた、各構成要素の少なくとも一部の組み合わせに結合要素や中継要素を加えて異なる実施の形態としてもよい。
　加えて、各構成要素の少なくとも一部の組み合わせに切り替え機能を加えて異なる実施の形態としてもよい。本実施の形態は、上述した各例で示した構成に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。なお、本明細書に記載された効果はあくまでも例示であって限定されるものではなく、また他の効果があってもよい。
　本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
　また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。
　したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。
　さらに、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。また、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
　さらに、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。また、例えば、上述したプログラムは、任意の装置において実行することができる。
　その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
　さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
　なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。
　さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
　また、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
　＜データストリームの停止方法＞
　（HEARTBEAT機能）
　HEARTBEAT機能は、リクエスタとレスポンダとの両方でサポートされている場合、セッションの存続要否の判断に用いることができる。
　ここで、リクエスタおよびレスポンダは、それぞれアプリケーションプロセッサ１２１２およびイメージセンサ１２１１に対応する構成であり、セッションによって１つ以上の通信チャネルを持つことができる。
　以降においては、推進装置の推進を制御する推進制御システム１６００において、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１がリクエスタであって、イメージセンサ１２１１に相当する撮像部１６１８がレスポンダである構成を例に用いてセッションが形成される例について説明を行う。もちろん、外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１がレスポンダであって、撮像部１６１８がリクエスタであってもよい。
　リクエスタまたはレスポンダは、セッション内にいる間、HEARTBEAT要求メッセージをHEARTBEAT周期（HeartbeatPeriod）内で送信する。HeartbeatPeriodは、例えば、PSK_EXCHANGE_RSP response message内またはSuccessful KEY_EXCHANGE_RSP response message内のParam1内にResponderが格納して指定する。
　HEARTBEAT要求メッセージ送信側は、HEARTBEAT要求メッセージ受信側からのHEARTBEAT_ACK応答メッセージまたはERROR応答メッセージが、「所定値（例えば、2）×HEARTBEAT周期（＝第1時間）」内で受信されない場合、セッションを終了する。
　HEARTBEAT要求メッセージ送信側は、HEARTBEAT要求メッセージ送信を再試行してもよく、再試行する前にHEARTBEAT要求メッセージ受信側からの応答を所定時間待機する。
　HEARTBEAT要求メッセージ受信側は、HEARTBEAT要求メッセージが「所定値（例えば、2）×HEARTBEAT周期」内で受信されない場合、セッションを終了する。
　このような場合、イメージセンサ１２１１に相当する撮像部１６１８に対する攻撃や誤動作などによって、撮像部１６１８の動作に起因するデータストリームの停止が生じる可能性がある。
　例えば、車、ドローン、ロボットなどの推進装置にイメージセンサ１２１１に相当する撮像部１６１８が搭載され、撮像部１６１８からのデータストリームが、推進装置の推進を制御する推進制御システム１６００の外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１で用いられる場合、データストリームが突然停止すると、推進制御に影響が生じて、最悪の場合、死傷事故を誘発する可能性がある。
　そこで、データストリームの停止が生じるような場合には、HEARTBEAT機能が無効化（HBEAT_CAP=0）されるようにして、リクエスタ（アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）に無断でレスポンダ（イメージセンサ１２１１に相当する撮像部１６１８）により、データストリームが停止されないようにする。
　リクエスタ（アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）に無断でデータストリームが停止されないようにされることにより、レスポンダ（イメージセンサ１２１１に相当する撮像部１６１８）の動作に起因するデータストリームの停止を回避することが可能となる。
　また、リクエスタ（アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）は、レスポンダ（イメージセンサ１２１１に相当する撮像部１６１８）から送信されるカウント値（例えば、メッセージカウンタの値）に基づいて、セッションの存続要否を判断してもよい。
　さらに、データストリームが突然停止するような場合、HEARTBEAT機能が有効化（HBEAT_CAP=1）されるようにして、HEARTBEAT周期に関するセッション終了を必須要件（例えば、”shall”または”must”などで表現される）ではなく必須要件外（例えば、”should”または”may”などで表現される任意要件）としてもよい。具体的には、HEARTBEAT周期に関するセッション終了を、HEARTBEAT要求メッセージ送信側は必須要件とし、HEARTBEAT要求メッセージ受信側は必須要件外としてもよい。また、HEARTBEAT周期に関するセッション終了を、HEARTBEAT要求メッセージ送信側は必須要件外とし、HEARTBEAT要求メッセージ受信側は必須要件としてもよい。また、HEARTBEAT周期に関するセッション終了を、HEARTBEAT要求メッセージ送信側は必須要件外とし、HEARTBEAT要求メッセージ受信側は必須要件外としてもよい。なお、一般に公開されているSPDM規格が、HEARTBEAT周期に関するセッション終了を必須要件ではなく必須要件外と定義してもよいし、SPDM規格の一部または全部を参照するセキュリティ規格がHEARTBEAT周期に関するセッション終了を必須要件ではなく必須要件外と定義してもよいし、SPDM規格を参照しないセキュリティ規格がHEARTBEAT周期に関するセッション終了を必須要件ではなく必須要件外と定義してもよい。
　また、レスポンダ（イメージセンサ１２１１に相当する撮像部１６１８）が、自らに対する攻撃や誤動作などの検知回路または予測回路を備え、自らや画像データに特異状況が発生する可能性あること（特異状況が既に発生したことも含む）を検知または予測してもよい。
　例えば、レスポンダ（イメージセンサ１２１１に相当する撮像部１６１８）が、HEARTBEAT_NAK応答メッセージを通信ホストである、リクエスタ（アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）に送信すれば、レスポンダ（撮像部１６１８）の不具合の発生を通知できるので、リクエスタ（外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）は、自らのデータストリームの停止の要否を判断できる（例えば、Valueとしては、0x00, 0x05-0x5F, 0x62, 0x6D-0x7DのReserved領域を新たに割り当て可能）。
　リクエスタ（外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）は、データストリームの停止を判断するとき、レスポンダ（撮像部１６１８）に対して、END_SESSION要求を送信し、データストリームを送信するための高速データ通信を停止させる。ただし、END_SESSION要求の送信は、データストリームの停止を判断（例えば、HEARTBEAT_NAK応答メッセージを受信、ERROR応答メッセージを受信、第１時間が経過）してから所定時間が経過した後に実行されてもよいし、推進状況が安全条件を満たすまで保留されてもよい。
　これにより、リクエスタ（外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１）は、例えば、データストリームを停止させても安全な状況下になった後に、データストリームを停止することができるので、推進制御に対する影響に起因する死傷事故の誘発を抑制することが可能となる。
　図１６５は、HEARTBEAT機能の有効化（HBEAT_CAP=1）または無効化（HBEAT_CAP=0）を設定するResponder flag fields definitionsの構成例を示している。これはレスポンダの構成例であるが、同様にリクエスタは、Requester flag fields definitionsに対応し、Responder flag fields definitions内のValueをResponderからRequesterに置き換えたHBEAT_CAPに対応してもよい。図１６６は、HEARTBEAT要求メッセージの構成例を示している。図１６７は、HEARTBEAT_ACK応答メッセージの構成例を示している。図１６８は、HEARTBEAT_NAK応答メッセージの構成例を示している。図１６９は、END_SESSION要求メッセージの構成例を示している。なお、SPDMVersionのValueをV1.1またはTBDとする構成例を示しているが、他のValue（例えば、V1.2（=0x12）、V1.3（=0x13）、V2.0（=0x20））であってもよい。また、一般に公開されているSPDM Version 1.1.0からの変更がある場合、例えばHEARTBEAT周期に関するセッション終了を必須要件ではなく必須要件外とする場合、SPDMVersionを他のValueとしてもよい。つまり、SPDMVersionのOffset、Bytes、またはValueの少なくとも何れかの記述は、一般に公開されているSPDM規格の最新仕様に準じてもよい。同様に、この出願に関わる図表または説明に用いられるOffset、Field、Bytes（Size in bytes）、Value、Size、Bit、Description、Name、Error code、Error data、ExtendedErrorData、ID、Vendor ID length、Registry or standards body name、bit assign、Remarks、eDT、eVC、Addr、Initial Value、Setting Data、Attribute、Detail、Embedded Data Format Code、Security MACまたはSecurity protocolなどの少なくとも何れかの記述は、SPDM規格、DMTF内規格、MIPI内規格、または他規格の最新仕様に準じてもよい。
　HEARTBEAT_NAK応答メッセージは、異常メッセージの特異メッセージである。また、HEARTBEAT_NAK応答メッセージは、例えばParam1やParam2などの領域を新たに定義して対応ビットを割り当てることによって、特異状況が通知されるようにしてもよい。すなわち、HEARTBEAT_NAK応答メッセージ内に、上述した何れかの他の特異メッセージが格納されても
よい。
　＜HEARTBEAT処理（その１）＞
　次に、図１７０のタイミングチャートを参照して、HEARTBEAT処理（その１）について説明する。
　ここで、図１７０の左部は、CCIホスト（リクエスタ）である、アプリケーションプロセッサ１２１２に相当する外部情報検出ユニット１６１７および／またはマイクロコンピュータ１６３１の動作タイミングが表されている。
　また、図１７０の右部は、CCIデバイス（レスポンダ）であるイメージセンサ１２１１に相当する撮像部１６１８の動作タイミングが表されている。
　すなわち、ステップＳ１７３１，Ｓ１７５１の処理により、CCIホスト（リクエスタ）が、CCIデバイス（レスポンダ）に対してPSK_FINISH要求メッセージを送信する（ステップＳ５０７またはＳ５２５の一部と同様）。
　ステップＳ１７５２，Ｓ１７３２の処理により、CCIデバイス（レスポンダ）が、CCIホスト（リクエスタ）に対してPSK_FINISH_RSP応答メッセージ送信する（ステップＳ５０７またはＳ５２５の一部と同様）。
　この処理により、HEARTBEAT機能が有効化状態になる。
　ステップＳ１７３３，Ｓ１７５３の処理により、CCIホスト（リクエスタ）が、HEARTBEAT要求メッセージをCCIデバイス（レスポンダ）に対して送信する。
　これに応じて、ステップＳ１７５４，Ｓ１７３４の処理により、CCIデバイス（レスポンダ）が、HEARTBEAT_ACK応答メッセージをCCIホスト（リクエスタ）に対して送信する。
　以降、CCIホスト（リクエスタ）は、HEARTBEAT周期（HeartbeatPeriod）毎にHEARTBEAT要求メッセージをCCIデバイス（レスポンダ）に対して送信し、これに応じて、CCIデバイス（レスポンダ）が、HEARTBEAT_ACK応答メッセージをCCIホスト（リクエスタ）に対して送信する処理が繰り返される。
　すなわち、ステップＳ１７３３乃至Ｓ１７３６およびＳ１７５３乃至Ｓ１７５６で示されるように、この処理が継続的に繰り返されている限り、通信状態が正常に確立された状態であることが認識される。
　ここで、CCIデバイス（レスポンダ）において異常が検出される状態になると、すなわち、通信状態が確立できていない状態になることを想定する。すると、ステップＳ１７３７，Ｓ１７５７の処理により、CCIホスト（リクエスタ）に送信されたHEARTBEAT要求メッセージに対して、ステップＳ１７５８，Ｓ１７３８の処理のように、CCIデバイス（レスポンダ）は、HEARTBEAT_NAK応答メッセージをCCIホスト（リクエスタ）に対して送信する。ただし、通信状態が確立できている状態で、異常メッセージとしてHEARTBEAT_NAK応答メッセージをCCIホスト（リクエスタ）に対して送信してもよい。
　ステップＳ１７３８の処理により、CCIホスト（リクエスタ）がHEARTBEAT_NAK応答メッセージを受信すると、ステップＳ１７３９の処理によりセッション（および高速データ通信）の終了を宣言するEND_SESSION要求メッセージをCCIデバイス（レスポンダ）に対して送信し、セッション鍵を破棄またはクリーンアップする。ただし、CCIホスト（リクエスタ）は、END_SESSION要求メッセージを送信してから所定時間が経過した後、CCIデバイス（レスポンダ）からの後述するEND_SESSION_ACK応答メッセージ、END_SESSION_NAK応答メッセージ、またはERROR応答メッセージを受信した後、などの場合にセッション鍵を破棄またはクリーンアップしてもよい。
　これに応じて、ステップＳ１７５９において、CCIデバイス（レスポンダ）は、END_SESSION要求メッセージを受信すると、ステップＳ１７６０において、END_SESSION_ACK応答メッセージをCCIホスト（リクエスタ）に送信し、セッション鍵を破棄またはクリーンアップして、セッション（および高速データ通信）を終了する。
　この処理により、HEARTBEAT機能が無効化状態になる。
　以上のような一連の処理により、CCIデバイスにおいて異常が発生しても、HEARTBEAT_NAK応答メッセージがCCIホストに供給され、一連の処理がなされた後に、セッション（および高速データ通信）が終了されて、データストリームが停止されることになるので、CCIデバイスが、CCIホストに対して無断でデータストリームを停止させるようなことが防止される。
　なお、何らかの原因で、HEARTBEAT要求メッセージが、HEARTBEAT周期（HeartbeatPeriod）毎にCCIデバイス（レスポンダ）において受信できない状態になった場合については、CCIホスト（リクエスタ）がEND_SESSION要求メッセージをCCIデバイス（レスポンダ）に対して送信し、セッション（および高速データ通信）を終了させる。
　すなわち、この場合も、セッション（および高速データ通信）の終了は、CCIホスト（リクエスタ）の判断により、END_SESSION要求メッセージが送信されることで実現されることになるので、やはり、CCIデバイスが、CCIホストに対して無断でデータストリームを停止させるようなことが防止される。
　＜HEARTBEAT処理（その２）＞
　CCIデバイス（レスポンダ）が異常を検出した場合や、所定時間（＝第1時間）内にHEARTBEAT要求メッセージが受信されない場合でも、所定時間（＝第2時間）内にCCIデバイス（レスポンダ）において、CCIホスト（リクエスタ）からのEND_SESSION要求メッセージが受信できないことがある。ここで、第１時間は、「所定値（例えば、2）×HEARTBEAT周期（HeartbeatPeriod）」に相当する時間であり、第２時間は、「所定値（例えば、2）×HEARTBEAT周期（HeartbeatPeriod）」に相当する時間が経過してから、END_SESSION要求メッセージが送信されるまでの更なる経過時間である。
　そこで、所定時間（＝第2時間）内にEND_SESSION要求メッセージがCCIデバイス（レスポンダ）で受信されない場合には、所定時間（＝第2時間）内にEND_SESSION要求メッセージがCCIデバイス（レスポンダ）で受信されないことを示すEND_SESSION_NAK応答メッセージを定義し、CCIデバイス（レスポンダ）からCCIホスト（リクエスタ）に対して通知できるようにしてもよい。
　図１７１は、所定時間（＝第2時間）内にEND_SESSION要求メッセージがCCIデバイス（レスポンダ）で受信されないことを示すEND_SESSION_NAK応答メッセージの構成例を示している。
　また、END_SESSION_NAK応答メッセージは、例えば、図１７１のParam1やParam2などの領域を新たに定義して対応ビットを割り当てることによって、特異状況が通知されるようにしてもよい。つまり、上述した何れかの特異メッセージまたは異常メッセージまたは付加情報が格納されてもよい。
　次に、図１７２，図１７３のフローチャートを参照して、HEARTBEAT処理（その２）について説明する。
　なお、図１７２のフローチャートは、CCIホスト（リクエスタ）の処理を表しており、図１７３のフローチャートは、CCIデバイス（レスポンダ）の処理を表している。
　ステップＳ１７７１（図１７２）において、CCIホスト（リクエスタ）は、PSK_FINISH要求メッセージをCCIデバイス（レスポンダ）に送信する。
　これに応じて、ステップＳ１７９１（図１７３）において、CCIデバイス（レスポンダ）は、PSK_FINISH要求メッセージが送信されてきたか否かに基づいて、PSK_FINISH_RSP応答メッセージをCCIホスト（リクエスタ）に送信するか否かを判定し、PSK_FINISH_RSP応答メッセージを送信すると判定するまで、同様の処理を繰り返す。
　そして、ステップＳ１７９１において、PSK_FINISH_RSP応答メッセージを送信すると判定された場合、ステップＳ１７９２において、CCIデバイス（レスポンダ）は、PSK_FINISH_RSP応答メッセージをCCIホスト（リクエスタ）に送信する。
　ここで、ステップＳ１７７２において、CCIホスト（リクエスタ）は、CCIデバイス（レスポンダ）からのPSK_FINISH_RSP応答メッセージを受信したか否かを判定し、PSK_FINISH_RSP応答メッセージを受信したと判定するまで、同様の処理を繰り返す。
　ステップＳ１７７２において、PSK_FINISH_RSP応答メッセージを受信したと判定した場合、処理は、ステップＳ１７７３に進む。
　ステップＳ１７７３において、CCIホスト（リクエスタ）は、HEARTBEAT要求メッセージをCCIデバイス（レスポンダ）に送信する。
　これに対応して、ステップＳ１７９３（図１７３）において、CCIデバイス（レスポンダ）は、HEARTBEAT要求メッセージを受信したか否かを判定する。
　ステップＳ１７９３において、HEARTBEAT要求メッセージを受信したと判定された場合、処理は、ステップＳ１７９４に進む。
　ステップＳ１７９４において、CCIデバイス（レスポンダ）は、HEARTBEAT_ACK応答メッセージをCCIホスト（リクエスタ）に送信し、処理は、ステップＳ１７９３に戻る。
　ここで、ステップＳ１７７４（図１７２）において、CCIホスト（リクエスタ）は、HEARTBEAT_ACK応答メッセージを受信したか否かを判定する。
　ステップＳ１７７４において、HEARTBEAT_ACK応答メッセージを受信したと判定した場合、処理は、ステップＳ１７７３に戻る。
　CCIホスト（リクエスタ）がHEARTBEAT要求をCCIデバイス（レスポンダ）に送信し、これに応じてCCIデバイス（レスポンダ）がHEARTBERAT_ACK応答メッセージをCCIホスト（リクエスタ）に返す処理を繰り返す限り、ステップＳ１７７３，Ｓ１７７４（図１７２）、およびステップＳ１７９３，Ｓ１７９４（図１７３）の処理が繰り返される。
　すなわち、CCIホスト（リクエスタ）とCCIデバイス（レスポンダ）との通信が確立した状態が維持される限り、CCIホスト（リクエスタ）がHEARTBEAT周期（HeartbeatPeriod）でHEARTBEAT要求メッセージをCCIデバイス（レスポンダ）に送信し、これに応じてCCIデバイス（レスポンダ）がHEARTBERAT_ACK応答メッセージをCCIホスト（リクエスタ）に返す処理を繰り返される。
　一方、ステップＳ１７９３（図１７３）において、HEARTBEAT要求メッセージを受信しないと判定された場合、処理は、ステップＳ１７９５に進む。
　ステップＳ１７９５において、CCIデバイス（レスポンダ）は、異常診断により異常が検出されたか否かを判定する。
　ステップＳ１７９５において、異常が検出されたと判定された場合、処理は、ステップＳ１７９６に進む。
　ステップＳ１７９６において、CCIデバイス（レスポンダ）は、HEARTBERAT_NAK応答メッセージをCCIホスト（リクエスタ）に送信する。
　これに対し、ステップＳ１７７４（図１７２）において、HEARTBERAT_ACK応答メッセージを受信しないと判定された場合、処理は、ステップＳ１７７５に進む。
　ステップＳ１７７５において、CCIデバイス（レスポンダ）は、HEARTBERAT_NAK応答メッセージを受信したか否かを判定する。
　ステップＳ１７７５において、HEARTBERAT_NAK応答メッセージを受信したと判定した場合、処理は、ステップＳ１７７７に進む。
　ステップＳ１７７７において、CCIホスト（リクエスタ）は、END_SESSION要求メッセージをCCIデバイス（レスポンダ）に送信する。
　ステップＳ１７７８において、CCIホスト（リクエスタ）は、セッション鍵を破棄またはクリーンアップして、セッション（および高速データ通信）を終了する。
　これに対して、ステップＳ１７９８（図１７３）において、CCIデバイス（レスポンダ）は、第１時間が経過した後、さらに、第２時間が経過するまでの間にEND_SESSION要求メッセージを受信したか否かを判定する。
　ステップＳ１７９８において、END_SESSION要求メッセージを受信したと判定した場合、処理は、ステップＳ１７９９に進む。
　ステップＳ１７９９において、CCIデバイス（レスポンダ）は、END_SESSION_ACK応答メッセージをCCIホスト（リクエスタ）に送信する。
　ステップＳ１８００において、CCIデバイス（レスポンダ）は、セッション鍵を破棄またはクリーンアップして、セッション（および高速データ通信）を終了する。
　すなわち、CCIデバイス（レスポンダ）において異常が検出されると、HEARTBERAT_NAK応答メッセージがCCIホスト（リクエスタ）に送信され、END_SESSION要求メッセージがCCIデバイス（レスポンダ）に送信され、これに応じてENDSESSION_ACK応答メッセージがCCIホスト（リクエスタ）に送信されて、CCIホスト（リクエスタ）、およびCCIデバイス（レスポンダ）の双方において、セッション鍵が破棄またはクリーンアップされて、セッション（および高速データ通信）が終了する。
　また、ステップＳ１７９５（図１７３）において、異常が検出されない場合、処理は、ステップＳ１７９７に進む。
　ステップＳ１７９７において、CCIデバイス（レスポンダ）は、直前のHEARTBERAT要求メッセージを受信してから第１時間が経過したか否かを判定する。
　ステップＳ１７９７において、直前のHEARTBERAT要求メッセージを受信してから第１時間が経過していないと判定された場合、処理は、ステップＳ１７９３に戻る。
　一方、ステップＳ１７７５において、HEARTBERAT_NAK応答メッセージを受信しない場合、処理は、ステップＳ１７７６に進む。
　ステップＳ１７７６において、CCIデバイス（レスポンダ）は、直前のHEARTBERAT要求を送信してから第１時間が経過したか否かを判定する。
　ステップＳ１７７６において、直前のHEARTBERAT要求メッセージを送信してから「所定値（例えば、2）×HEARTBEAT周期（HeartbeatPeriod）」に相当する第１時間が経過していないと判定された場合、処理は、ステップＳ１７７４に戻る。
　すなわち、CCIデバイス（レスポンダ）において、HEARTBEAT要求メッセージを受信できない状態で、異常が検出されない場合、第１時間が経過するまでは、ステップＳ１７７４乃至Ｓ１７７６（図１７２）の処理、並びに、ステップＳ１７９３，Ｓ１７９５，Ｓ１７９７（図１７３）の処理が繰り返される。
　そして、ステップＳ１７７６（図１７２）において、第１時間が経過すると、処理は、ステップＳ１７７７，Ｓ１７７８に進み、CCIホスト（リクエスタ）は、END_SESSION要求メッセージを送信して、セッション鍵を破棄またはクリーンアップして、セッション（および高速データ通信）を終了する。
　また、CCIデバイス（レスポンダ）においては、ステップＳ１７９７（図１７３）において、第１時間が経過すると、処理は、ステップＳ１７９８に進む。
　この場合、処理は、ステップＳ１７９８乃至Ｓ１８００の処理がなされる。
　したがって、CCIデバイス（レスポンダ）に異常が検出されない状態であっても、CCIデバイス（レスポンダ）において、HEARTBEAT要求メッセージが第１時間以上受信できない状態が継続されると、CCIホスト（リクエスタ）からのEND_SESSION要求メッセージに基づいて、セッション（および高速データ通信）が終了される。
　さらに、ステップＳ１７９８において、前回HEARTBEAT要求メッセージを受信してから、第１時間が経過した後、さらに、第２時間が経過するまでの間にEND_SESSION要求メッセージを受信しないと判定した場合、処理は、ステップＳ１８０１に進む。
　ステップＳ１８０１において、CCIデバイス（レスポンダ）は、END_SESSION_NAK応答メッセージをCCIホスト（リクエスタ）に送信する。
　これにより、何らかの原因で、CCIデバイス（レスポンダ）において、END_SESSION要求メッセージが受信できない状態が、前回HEARTBEAT要求メッセージを受信してから、第１時間が経過した後、さらに、第２時間以上継続した場合には、CCIホスト（リクエスタ）に対してEND_SESSION_NAK応答メッセージが送信されて、セッション（および高速データ通信）が終了される。
　この場合、CCIデバイス（レスポンダ）が自身の判断で高速データ通信を終了することになるが、CCIホスト（リクエスタ）に対してEND_SESSION_NAK応答メッセージが送信されるので、CCIホスト（リクエスタ）は、CCIデバイス（レスポンダ）において高速データ通信が終了したことを認識することができる。
　また、この処理では、異常が検出された場合、所定時間（＝第１時間）を待つ前に、CCIデバイス（レスポンダ）からCCIホスト（リクエスタ）に対して早急に異常が通知される。さらに、HEARTBEAT_NAK応答メッセージは、上述した特異メッセージ、異常メッセージまたは付加情報で置き換えられてもよい。なお、ステップＳ１７９７（第１時間が経過したか？）の処理とステップＳ１７９８（第２時間内にEND_SESSION要求を受信したか？）の処理との間にステップＳ１７９６（HEARTBEAT_NAK応答を送信する）と同様な処理を追加してもよい。つまり、第１時間が経過した場合、HEARTBEAT_NAK応答を送信してもよい。また、異常を検出した場合のHEARTBEAT_NAK応答と第１時間が経過した場合のHEARTBEAT_NAK応答とで、メッセージの一部（例えば、Param1、Param2）または全部が異なってもよい。
　＜HEARTBEAT処理（その３）＞
　HEARTBEAT_NAK応答、およびEND_SESSION_NAK応答メッセージは、少なくともいずれか一方を省略するようにしてもよい。
　ここで、図１７４，図１７５のフローチャートを参照して、HEARTBEAT_NAK応答メッセージ、およびEND_SESSION_NAK応答メッセージの両方を省略するようにしたHEARTBEAT処理（その３）について説明する。
　なお、図１７４のフローチャートは、CCIホスト（リクエスタ）の処理を表しており、図１７５のフローチャートは、CCIデバイス（レスポンダ）の処理を表している。
　ここで、図１７４のステップＳ１８１１乃至Ｓ１８１７の処理は、図１７２のステップＳ１７７１乃至Ｓ１７７４、およびステップＳ１７７６乃至Ｓ１７７８の処理に対応しているので、その説明は省略する。また、図１７５のステップＳ１８３１乃至Ｓ１８３８の処理は、図１７３のステップＳ１７９１乃至Ｓ１７９４、およびステップＳ１７９７乃至Ｓ１８００の処理に対応しているので、その説明は省略する。
　すなわち、図１７４のCCIホスト（リクエスタ）の処理においては、異常診断結果に基づいた異常の有無に拘わらず、前回HEARTBEAT要求メッセージを受信してから第１時間が経過した場合については、CCIデバイス（レスポンダ）と通信できない状態になったものとみなし、END_SESSION要求メッセージが送信されて、セッション（および高速データ通信）が終了される。
　また、図１７５のCCIデバイス（レスポンダ）の処理においては、前回HEARTBEAT_ACK応答メッセージを受信してから第１時間が経過するまでに次のHEARTBEAT_ACK応答メッセージが受信できない場合、CCIホスト（リクエスタ）と通信できない状態になったものとみなされ、さらに、第２時間が経過するまでに、END_SESSION要求メッセージが送信されてきたときについては、END_SESSION_ACK応答メッセージが送信されて、セッション（および高速データ通信）が終了される。
　一方、さらに、第２時間が経過するまでに、END_SESSION要求メッセージが送信されてこないときについては、そのままセッション（および高速データ通信）が終了される。
　以上の処理においても、何らかの原因で、HEARTBEAT要求メッセージが、HEARTBEAT周期（HeartbeatPeriod）毎にCCIデバイス（レスポンダ）において受信できない状態になった場合については、セッション（および高速データ通信）が終了させることが可能となる。
　また、この処理においても、セッション（および高速データ通信）の終了は、基本的には、CCIホスト（リクエスタ）の判断により、END_SESSION要求メッセージが送信されることで実現されることになるので、やはり、CCIデバイスが、CCIホストに対して無断でデータストリームを停止させるようなことが防止される。ただし、この処理では、第２時間以上END_SESSION要求メッセージが受信できない場合については、CCIデバイス（レスポンダ）の判断で、高速データ通信からなるセッションが終了される。
　＜HEARTBEAT処理の応用例１＞
　CCIデバイス（レスポンダ）は、エラーや不具合などの異常が発生した場合に、CCIホスト（リクエスタ）にERROR応答メッセージを送信するようにしてもよい。
　すなわち、CCIデバイス（レスポンダ）は、CCIホスト（リクエスタ）に対して、HEARTBEAT_NAK応答メッセージ、およびEND_SESSION_NAK応答メッセージの少なくとも何れかの代わりに、HEARTBEAT機能に関連するエラーまたは不具合に対応するERROR応答メッセージを送信してもよい。
　ERROR応答メッセージは、例えば、図１７６で示されるような構成とされる。図１７６で示されるように、ERROR応答メッセージには、例えば、Param1（Error code）、Param2（Error data）およびExtendedErrorDataの領域が定義されるようにして、対応ビットを割り当てることにより、特異状況が通知されるようにしてもよい。
　つまり、上述した何れかの特異メッセージ、異常メッセージ、および付加情報の少なくともいずれかが格納されてもよい。また、HEARTBEAT機能またはEND_SESSION要求メッセージなどに関連するエラーまたは不具合に対応するERROR応答メッセージとして、既存のError code（例えば、Unspecified、InvalidSession（Value：0x02、Description：The record layer used an invalid session ID.、Error data：This shall be the invalid session ID.、ExtendedErrorData：No extended error data is provided.））が用いられてもよい。
　図１７７は、Error codeとError dataの設定例を示している。ただし、Reserved領域またはVendor/Other Standards Defined領域が、HEARTBEAT機能またはEND_SESSION要求メッセージなどに関連するエラーまたは不具合に対応するエラー領域として新たに定義されてもよい。また、一般に公開されているSPDM規格によって定義されるSPDM仕様内のError code and error data表内の設定が用いられてもよい。また、図１７８は、ExtendedErrorDataの設定例を示している。
　＜HEARTBEAT処理の応用例２＞
　HEARTBEAT要求メッセージを、VENDOR_DEFINED_REQUEST要求メッセージで疑似的に定義すると共に、HEARTBEAT_ACK応答（およびHEARTBEAT_NAK応答）メッセージを、VENDOR_DEFINED_RESPONSE応答メッセージで疑似的に定義することにより、HEARTBEAT要求およびHEARTBEAT_ACK応答の代わりに用いることで、疑似的にHEARTBEAT機能を実現するようにしてもよい。
　以降においては、VENDOR_DEFINED_REQUEST要求メッセージおよびVENDOR_DEFINED_RESPONSE応答メッセージにより実現される、疑似的なHEARTBEAT機能を、単に、疑似HEARTBEAT機能と称する。
　すなわち、疑似HEARTBEAT機能が用いられる場合、HEARTBEAT機能は無効化（HBEAT_CAP=0）することが可能となる。
　なお、図１７９は、疑似HEARTBEAT機能が実現される場合のRegistry or standards body IDの設定例を示している。ただし、一般に公開されているSPDM規格によって定義されるSPDM仕様内のRegistry or standards body ID表内の設定が用いられてもよい。つまり、本技術は、DMTF（Distributed Management Task Force）、TCG（Trusted Computing Group）、USB（Universal Serial Bus）、PCI-SIG（Peripheral Component Interconnect Special Interest Group）、IANA（Internet Assigned Numbers Authority）、HDBaseT、MIPI（Mobile Industry Processor Interface）、CXL（Compute Express Link）、JEDEC（Joint Electron Device Engineering Council）などのうちの少なくとも何れかのstandardsbodyが定義する規格内に適用されてもよいし、これらのうちの少なくとも何れかのstandards bodyまたは他のstandards bodyが定義する規格内のHEARTBEAT同等機能またはEND_SESSION同等機能に適用されてもよい。また、図１８０，図１８１は、それぞれ疑似HEARTBEAT機能が実現される場合のVENDOR_DEFINED_REQUEST要求メッセージおよびVENDOR_DEFINED_RESPONSE応答メッセージの設定例を示している。ただし、疑似HEARTBEAT機能は、SPDM規格に準じる他メッセージまたはCCI規格に準じるメッセージまたは他規格に準じるメッセージなどで定義されてもよい。同様に、END_SESSION要求メッセージを、VENDOR_DEFINED_REQUEST要求メッセージで疑似的に定義すると共に、END_SESSION_ACK応答（およびEND_SESSION_NAK応答）メッセージを、VENDOR_DEFINED_RESPONSE応答メッセージで疑似的に定義することにより、END_SESSION要求およびEND_SESSION_ACK応答の代わりに用いることで、疑似的にEND_SESSION機能を実現するようにしてもよい。以降においては、VENDOR_DEFINED_REQUEST要求メッセージおよびVENDOR_DEFINED_RESPONSE応答メッセージにより実現される、疑似的なEND_SESSION機能を、単に、疑似END_SESSION機能と称する。ただし、疑似END_SESSION機能は、SPDM規格に準じる他メッセージまたはCCI規格に準じるメッセージまたは他規格に準じるメッセージなどで定義されてもよい。
　＜画像系通信における鍵更新＞
　本技術は、例えばMIPI（Mobile Industry Processor Interface）AllianceのCSI（Camera Serial Interface）規格またはDSI（Display Serial Interface）規格などに適用する際に好適な、セッション鍵（暗号化鍵またはMAC鍵）の鍵更新を開示する。本技術は、CSI-2規格またはDSI-2規格に適用する際に特に好適である。なお、CSI-2規格またはDSI-2規格は、制御系通信（CCI通信と称する）と画像系通信（被制御系通信またはCSI-2通信またはDSI-2通信と称する）とを含む。制御系通信は、書き込み命令（CCI Write）、読み出し命令（CCI Read）、読み出し応答（CCI Read戻り値）などの何れかの送信を含み、双方向通信である。画像系通信は、フレームスタート、埋込データ、画像データ、ユーザ定義データ、フレームエンドなどの何れかの送信を含み、片方向通信である。そして、本技術は、制御系通信を利用して導出したセッション鍵（暗号化鍵またはMAC鍵）を画像系通信に適用する際に好適である。一方、制御系通信および画像系通信にセキュリティ機能を付加するために、DMTF（Distributed Management Task Force）によるSPDM（Security Protocol and Data Model）規格を適用することが可能である。そのため、本技術は、SPDM規格を双方向通信である制御系通信および片方向通信である被制御系通信に適用する際に好適だが、SPDM規格に準じる必要はない。
　　＜SPDM＞
　非特許文献１に記載のDMTFによるSPDM規格では、図１８２に示されるように、鍵スケジュールから、4つのメジャーシークレット（Major secrets）（S0：Request-direction handshake secret、S1：Response-direction handshake secret、S2：Request-direction data secret、S3：Response-direction data secret）が導出されることが可能であり、少なくとも１つのエクスポートマスターシークレット（Export Master Secret）が導出されることが可能である。そして、これらのシークレット（セッション秘密）からはセッション鍵（暗号化鍵またはMAC鍵）が導出されることが可能である。
　各シークレット（secret）は特定の送信方向に適用され、特定の時間枠内でのみ有効である。これら4つのメジャーシークレットはそれぞれ、ALGORITHMS応答内で選択されたAEAD機能内で使用されるセッション鍵（暗号化鍵またはMAC鍵）を導出するために用いられる。また、 AEAD機能内で使用される初期化ベクトル（IV）を導出するために用いられてもよい。
　S0およびS1はセッションハンドシェイク段階（Session handshake phase）中でのみ使用され、KEY_EXCHANGEまたはPSK_EXCHANGEの後からFINISHまたはPSK_FINISHまでの、全ての要求にS0が、全ての応答にS1が、それぞれ適用されることが可能。また、S0はSPDMメッセージ内のRequesterVerifyData領域を、S1はSPDMメッセージ内のResponderVerifyData領域を、それぞれ計算するために使用されるFinished_keyの導出にそれぞれ用いられる。
　S2およびS3は、セッションのアプリケーション段階（Application phase）中に送信される全てのデータに使用されることが可能であり、S2はリクエスタからレスポンダへ移動する全てのデータにのみ適用され、S3はレスポンダからリクエスタへ移動する全てのデータにのみ適用される。
　これらの4つのMajor secretsを更新する場合、非特許文献１に記載されている12.8 Major secrets updateを適用すればよい。
　SPDM鍵交換が成功した後は、追加のセッション鍵（暗号化鍵またはMAC鍵）をExport Master Secretから導出することができる。Export Master Secretを更新する場合、非特許文献１に記載されている12.8 Major secrets updateを修正または微修正した定義を適用してもよいし、新たな定義を適用してもよい。
　　＜エクスポートマスターシークレットの更新＞
　例えば、図１８３に示されるように、Export Master Secretを更新し、新たなセッション鍵（暗号化鍵またはMAC鍵）を導出して画像系通信へ適用してもよい。
　非特許文献１に記載のDMTFによるSPDM規格では、Export Master Secretを更新することができないため、図１８３に示されるように、KEY_UPDATE operationsとしてExport Master Secretを更新するためのOperation（例えば、UpdateExportMaster）を追加する。ValueおよびDescriptionは一例だが、さらに異なるValueを定義し、他のExport Master Secretがあれば他のExport Master Secretを更新するためのOperation（例えば、Export Master Secret 1, Export Master Secret 2,…）を追加してもよい。
　　＜鍵使用開始タイミングが未定、鍵検証機能に非対応＞
　上述のようにExport Master Secretを更新できるようにして非特許文献１に記載のDMTFによるSPDM規格を画像系通信に適用した場合、要求方向データシークレットおよび応答方向データシークレットについては、KEY_UPDATE request messageおよびKEY_UPDATE_ACK response messageによって、新たなシークレットおよびセッション鍵（暗号化鍵またはMAC鍵）の使用開始タイミングが定まる。これに対して、エクスポートマスターシークレットについては、新たなシークレットおよびセッション鍵（暗号化鍵またはMAC鍵）の使用開始タイミングが定まらないおそれがあった。
　また、要求方向データシークレットおよび応答方向データシークレットについては、新たなセッション鍵（暗号化鍵またはMAC鍵）が正しく導出されたのかをVerifyNewKeyのOperationによって検証できるが、エクスポートマスターシークレットについては新たなセッション鍵（暗号化鍵またはMAC鍵）が正しく導出されたのかをVerifyNewKeyのOperationによって検証できないおそれがあった。
　そこで、新セッション鍵の使用開始タイミングを指定するようにする。また、新セッション鍵を検証するようにする。
　　＜新セッション鍵の使用開始タイミングの指定＞
　図１８４は、図７５のＡに示されるイメージセンサ１２１１とアプリケーションプロセッサ１２１２との間での、セッション鍵を用いた通信処理の例を示すフローチャートである。イメージセンサ１２１１は、図７６に示されるような構成を有する。アプリケーションプロセッサ１２１２は、図７７に示されるような構成を有する。
　アプリケーションプロセッサ１２１２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、CCIホスト（リクエスタ）としての機能を備え、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、CSI-2ホストとしての機能を備えている。イメージセンサ１２１１において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、CCIデバイス（レスポンダ）としての機能を備え、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、CSI-2デバイスとしての機能を備えている。CCIホストは、CCIデバイスへ要求メッセージを送信し、その受信に応じてCCIデバイスはCCIホストへ応答メッセージを送信する。
　CCIホストとCSI-2ホストとは一体または別体であり、CCIデバイスとCSI-2デバイスとは一体または別体である。また、CCIホストとCCIデバイスとの間は双方向の低速コマンド送信であり、CSI-2ホストとCSI-2デバイスとの間は片方向の高速データ送信である。
　ステップＳ２００１およびステップＳ２０１１において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCCIホストと拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCCIデバイスとの間で、GET_VERSION要求およびVERSION応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、エンドポイントのSPDMバージョンを取得する。
　ステップＳ２００２およびステップＳ２０１２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCCIホストと拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCCIデバイスとの間で、GET_CAPABILITIES要求およびCAPABILITIES応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、エンドポイントのSPDM機能を取得する。
　ステップＳ２００３およびステップＳ２０１３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCCIホストと拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCCIデバイスとの間で、NEGOTIATE_ALGORITHMS要求およびALGORITHMS応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０と暗号アルゴリズムを交渉する。
　ステップＳ２００４およびステップＳ２０１４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCCIホストと拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCCIデバイスとの間で、PSK_EXCHANGE要求およびPSK_EXCHANGE_RSP応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６および拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、セッション秘密や暗号化鍵などのCCI向けのセッション鍵を導出する。
　ステップＳ２００５およびステップＳ２０１５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCCIホストと拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCCIデバイスとの間で、PSK_FINISH要求およびPSK_FINISH_RSP応答が行われる。これにより、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６がPSK（PSK：Pre-shared key）を知っていて、ステップＳ２００４およびステップＳ２０１４で導出されたCCI向けのセッション鍵が正しいことをレスポンダへ証明する。
　ステップＳ２００６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCCIホストは、CSI-2向けセッション鍵、アルゴリズム、他パラメータ等の情報を、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCSI-2ホストに供給する。ステップＳ２０２１において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCSI-2ホストは、それらの情報を取得する。
　ステップＳ２０１６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCCIデバイスは、CSI-2向けセッション鍵、アルゴリズム、他パラメータ等の情報を、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCSI-2デバイスに供給する。ステップＳ２０３１において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCSI-2デバイスは、それらの情報を取得する。
　これらの情報を得た拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６のCSI-2ホストと拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０のCSI-2デバイスは、それ以降、そのセッション鍵を用いた通信を行う（ステップＳ２０２２およびステップＳ２０３２以降の矢印群）。
　CCI向けでは、UpdateKeyまたはUpdateAllKeysのOperationが適用されたKEY_UPDATE要求およびKEY_UPDATE_ACK応答と、VerifyNewKeyのOperationとが適用されたKEY_UPDATE要求およびKEY_UPDATE_ACK応答と、によってCCIホストとCCIデバイスとの間でセッション秘密およびセッション鍵が更新される。
　CSI-2向けでは、例えば、CCIホストがCSI-2向けセッション鍵更新のトリガを受けると、UpdateExportMasterのOperationが適用されたKEY_UPDATE要求およびKEY_UPDATE_ACK応答によってCCIホストとCCIデバイスとの間でセッション秘密およびセッション鍵が更新され、その更新されたセッション鍵（新セッション鍵）がCSI-2ホストとCSI-2デバイスとの間に適用される（ステップＳ２００８およびステップＳ２０１７）。つまり、CSI-2向け鍵更新では、1組のKEY_UPDATE要求およびKEY_UPDATE_ACK応答を省略可能である。
　ただし、CCIホストとCCIデバイスとの間の低速コマンド送信を利用して更新した新セッション鍵を、CSI-2ホストとCSI-2デバイスとの間の高速データ送信に適用する都合上、新旧のセッション鍵の誤使用を避けるために、新セッション鍵の使用開始タイミングを指定することが望ましい。
　画像系通信（CSI-2）は制御系通信（CCI）の一部または全部よりも、高速であり、送信される総データ量が大きいことが一般的である。そのため、制御系通信で更新した新セッション鍵（暗号化鍵またはMAC鍵）を画像系通信に適用させる場合、新セッション鍵の使用開始タイミングがセンサとプロセッサとの間で不一致になる可能性があった。
　そこで、タイミング不一致を避けるために、パケットを拡張し、新セッション鍵の使用開始タイミングを指定する。例えば、拡張パケットのパケットヘッダにおいて、図１８５に示されるように、ePH2[TBD] = 1'b1の拡張パケットを送信することにより、新セッション鍵の使用開始タイミングを指定する。
　その場合の処理の流れの例を図１８６のフローチャートを参照して説明する。CSI-2ホストがステップＳ２０５１においてセッション鍵を導出し、CSI-2デバイスがステップＳ２０６１においてセッション鍵を導出する。その後、そのセッション鍵（現在のセッション鍵）を用いて通信が行われる。CSI-2デバイスは現在のセッション鍵を用いてePH2[TBD]= 1'b0でVC1拡張パケットを送信し（ステップＳ２０６２）、CSI-2ホストはそれを受信する（ステップＳ２０５２）。以降の通信は同様に行われる。
　その後、所定のタイミングにおいて、CSI-2ホストおよびCSI-2デバイスは、それぞれ新セッション鍵を導出する（Ｓ２０５３、Ｓ２０６３）。CSI-2デバイスは、現在のセッション鍵を用いてePH2[TBD] = 1'b1でVC1拡張パケットを送信し（ステップＳ２０６４）、CSI-2ホストはそれを受信する（ステップＳ２０５４）。これにより新セッション鍵の使用開始タイミングが指定される。
　その後、その新セッション鍵を用いて通信が行われる。つまり、上記の使用開始タイミング指定に応じて、セッション鍵が更新され、新セッション鍵の使用が開始される。CSI-2デバイスは新セッション鍵を用いてePH2[TBD] = 1'b0でVC1拡張パケットを送信し（ステップＳ２０６６）、CSI-2ホストはそれを受信する（ステップＳ２０５５）。以降の通信は同様に行われる。
　なお、所定のタイミングにおいて、CSI-2ホストおよびCSI-2デバイスは、それぞれ、更新前のセッション鍵（古いセッション鍵）を破棄する（Ｓ２０５６、Ｓ２０６５）。
　このようにすることにより、新セッション鍵の使用開始タイミングを指定することができるので、適切なタイミングにおいてセッション鍵を更新することができる。また、このように新セッション鍵の使用開始タイミングを拡張パケットヘッダによって指定することにより、任意のライン（任意のタイミング）で新セッション鍵を使用開始することができる。
　以上において、拡張パケットヘッダにより新セッション鍵の使用開始タイミングを指定する例を説明したが、埋込データまたは読み出し応答（帯域内割込み含む）等によって新セッション鍵の使用開始タイミングを指定するようにしてもよい。
　なお、図１８６は古いセッション鍵を廃棄できる最速なタイミングを図示しているが、古いセッション鍵を廃棄するタイミングは遅らせてもよい。その場合、新セッション鍵および古いセッション鍵が保持されるので、もし古いセッション鍵が必要になる状況が発生しても対応できる。例えば、次の新セッション鍵を導出する直前まで、古いセッション鍵を廃棄するタイミングを遅らせてもよい。その場合、センサおよびプロセッサは、常時または略常時２種類のセッション鍵を保持する。他の例も同様である。
　なお、拡張パケットの仮想チャネルがVC1である例を用いて説明しているが、別仮想チャネルの場合も同様である。すなわち、VC1をVC2またはVC3などに置き換えてもよいし、VC1を省略してもよい。
　拡張パケットヘッダによって、センサが、新セッション鍵の使用開始タイミングを指定してもよい。その場合のアプリケーションプロセッサ１２１２の処理であるプロセッサ処理の流れの例を図１８７のフローチャートを参照して説明する。
　プロセッサ処理が開始されると、ステップＳ２１０１において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新が必要であるか否かを判定し、必要になるまで待機する。VC1鍵更新が必要であると判定された場合、処理はステップＳ２１０２に進む。
　ステップＳ２１０２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新命令を送信する。また、ステップＳ２１０３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を導出する。
　ステップＳ２１０４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、ePH2[TBD] = 1'b1のVC1拡張パケットを受信したか否かを判定し、受信したと判定されるまで待機する。受信したと判定された場合、処理はステップＳ２１０５に進む。
　ステップＳ２１０５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、ePH2[TBD] = 1'b0のVC1拡張パケットを受信したか否かを判定し、受信したと判定されるまで待機する。受信したと判定された場合、処理はステップＳ２１０６に進む。
　ステップＳ２１０６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、古いセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２１０７において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の使用を開始する。
　ステップＳ２１０７の処理が終了するとプロセッサ処理が終了する。
　図１８８のフローチャートを参照して、イメージセンサ１２１１の処理であるセンサ処理の流れの例を説明する。このセンサ処理は、図１８７のプロセッサ処理に対応する処理である。
　センサ処理が開始されると、ステップＳ２１４１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、図１８７のステップＳ２１０２においてアプリケーションプロセッサ１２１２から送信されたVC1鍵更新命令を受信したか否かを判定し、受信したと判定されるまで待機する。VC1鍵更新命令を受信したと判定された場合、処理はステップＳ２１４２に進む。
　ステップＳ２１４２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を導出する。
　ステップＳ２１４３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1拡張パケットを送信するか否かを判定し、送信すると判定されるまで待機する。送信すると判定された場合、処理はステップＳ２１４４に進む。
　ステップＳ２１４４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、ePH2[TBD] = 1'b1でVC1拡張パケットを送信する。このVC1拡張パケットは、ステップＳ２１０４においてアプリケーションプロセッサ１２１２により受信される。
　ステップＳ２１４５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1拡張パケットを送信するか否かを判定し、送信すると判定されるまで待機する。送信すると判定された場合、処理はステップＳ２１４６に進む。
　ステップＳ２１４６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、古いセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２１４７において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の使用を開始する。
　ステップＳ２１４８において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、ePH2[TBD] = 1'b0でVC1拡張パケットを送信する。
　ステップＳ２１４８の処理が終了するとセンサ処理が終了する。
　アプリケーションプロセッサ１２１２が上述のようにプロセッサ処理を行い、イメージセンサ１２１１が上述のようにセンサ処理を行うことにより、図１８６のフローチャートのように、新セッション鍵の使用開始タイミングを指定して、セッション鍵を更新することができる。
　　＜セッション鍵の検証＞
　KEY_UPDATE要求メッセージ内のKEY_UPDATE operations内のVerifyNewKeyのOperationは、双方向通信の制御系通信（CCI）に適用されることが可能だが、片方向通信の画像系通信（CSI-2）に適用されることが不可能である。そのため、制御系通信で更新した新セッション鍵（暗号化鍵またはMAC鍵）が正しく導出されたことを、画像系通信において検証する。
　具体的には例えば、センサは、センサが導出した新セッション鍵を用いて埋込データの一部（第2埋込データ）のMAC値を演算し、パケットデータ内に格納された第2埋込データと拡張パケットフッタ内に格納されたMAC値とをプロセッサへ送信する。そして、プロセッサは、第2埋込データおよびMAC値を受信し、プロセッサが導出した新セッション鍵を用いて第2埋込データのMAC値を演算し、MAC値の演算結果と受信結果が一致する場合に新セッション鍵が正しく導出されたと判断する。この新セッション鍵検証は、ラインMAC方式の場合に好適である。
　その場合の処理の流れの例を図１８９のフローチャートを参照して説明する。CSI-2ホストがステップＳ２２０１においてセッション鍵を導出し、CSI-2デバイスがステップＳ２２２１においてセッション鍵を導出する。その後、そのセッション鍵（現在のセッション鍵）を用いて通信が行われる。CSI-2デバイスは現在のセッション鍵を用いてePH2[TBD]= 1'b0でVC1拡張パケットを送信し（ステップＳ２２２２）、CSI-2ホストはそれを受信する（ステップＳ２２０２）。以降の通信は同様に行われる。
　その後、所定のタイミングにおいて、CSI-2ホストおよびCSI-2デバイスは、それぞれ新セッション鍵を導出する（Ｓ２２０３、Ｓ２２２３）。CSI-2デバイスは、現在のセッション鍵を用いてePH2[TBD] = 1'b0でVC1第１埋込データを送信し（ステップＳ２２２４）、CSI-2ホストはそれを受信する（ステップＳ２２０４）。これにより新セッション鍵の使用開始タイミングが指定される。
　そして、CSI-2デバイスは新セッション鍵を用いてePH2[TBD] = 1'b0でVC1第２埋込データを送信し（ステップＳ２２２５）、CSI-2ホストはそれを受信する（ステップＳ２２０５）。この第２の埋込データを用いて新セッション鍵の検証が開始される。つまり、ステップＳ２２０６において、CSI-2ホストは、新セッション鍵を検証する。
　つまり、上述したように、CSI-2デバイスは、CSI-2デバイスが導出した新セッション鍵を用いて埋込データの一部（第2埋込データ）のMAC値を演算し、パケットデータ内に格納された第2埋込データと拡張パケットフッタ内に格納されたMAC値とをCSI-2ホストへ送信する。そして、CSI-2ホストは、その第2埋込データおよびMAC値を受信し、CSI-2ホストが導出した新セッション鍵を用いて第2埋込データのMAC値を演算し、MAC値の演算結果と受信結果とを比較する。CSI-2ホストは、両者が一致する場合、新セッション鍵が正しく導出されたと判断する。
　新セッション鍵が正しく導出されたと判定された場合、セッション鍵の更新が行われる。つまり、新セッション鍵の使用が開始される。
　そのため、CSI-2デバイスは、現在のセッション鍵を用いてePH2[TBD] = 1'b1でVC1フレームエンドを送信し（ステップＳ２２２６）、CSI-2ホストはそれを受信する（ステップＳ２２０７）。
　そして、CSI-2デバイスは、新セッション鍵を用いてePH2[TBD] = 1'b0でVC1フレームスタートを送信し（ステップＳ２２２８）、CSI-2ホストはそれを受信する（ステップＳ２２０８）。その後、CSI-2デバイスは、新セッション鍵を用いてePH2[TBD] = 1'b0でVC1拡張パケットを送信し（ステップＳ２２２９）、CSI-2ホストはそれを受信する（ステップＳ２２１０）。以降の通信は同様に行われる。
　なお、所定のタイミングにおいて、CSI-2ホストおよびCSI-2デバイスは、それぞれ、更新前のセッション鍵（古いセッション鍵）を破棄する（Ｓ２２０９、Ｓ２２２７）。
　このようにすることにより、新セッション鍵の検証を行うことができるので、正しいセッション鍵に更新することができる。つまり、セッション鍵の更新をより正確に行うことができる。
　なお、セッション鍵の検証手順は、この例に限定されない。例えば、センサは、センサが導出した新セッション鍵を用いて埋込データの一部（第2埋込データ）を暗号化してプロセッサへ送信する。そして、プロセッサは、第2埋込データを受信し、プロセッサが導出した新セッション鍵を用いて第2埋込データを復号し、その結果が想定通りであれば新セッション鍵が正しく導出されたと判断する。このような手順でセッション鍵の検証を行ってもよい。
　ところで、第1埋込データと第2埋込データとの送信順を異ならせてもよい。また、第2埋込データの後に第３埋込データ（セッション鍵、ePH2[TBD]=1’b0）を送信してもよい。また、埋込データの行数は、新セッション鍵検証の有無に応じて可変でも固定でもよい。また、埋込データの一部（第2埋込データ）を用いて新セッション鍵を検証する例を用いて説明したが、同様に、画像データの一部（第2画像データ）またはユーザ定義データの一部（第2ユーザ定義データ）などの画像系通信内データ（特に、拡張パケット内のパケットデータ）の一部または全部を用いて新セッション鍵を検証してもよい。
　この場合のプロセッサ処理の流れの例を図１９０のフローチャートを参照して説明する。拡張パケットヘッダを用いる場合、SPDMのVerifyNewKeyはCSI-2に適用できないためCSI-2の枠組みの中で埋込データの一部を用いて新セッション鍵を検証する。
　プロセッサ処理が開始されると、ステップＳ２３０１において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新が必要であるか否かを判定し、必要になるまで待機する。VC1鍵更新が必要であると判定された場合、処理はステップＳ２３０２に進む。
　ステップＳ２３０２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新命令を送信する。また、ステップＳ２３０３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を導出する。
　ステップＳ２３０４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1第２埋込データを受信したか否かを判定し、受信したと判定されるまで待機する。受信したと判定された場合、処理はステップＳ２３０５に進む。
　ステップＳ２３０５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を仮使用した第２埋込データを検証する。そして、ステップＳ２３０６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、その検証結果に基づいて、新セッション鍵が正しいか否かを判定する。新セッション鍵が正しくないと判定された場合、処理はステップＳ２３０７に進む。
　ステップＳ２３０７において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の破棄またはクリーンアップを開始する。ステップＳ２３０８において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、現在のセッション鍵の継続命令を送信する。つまり、セッション鍵の更新を中止する。ステップＳ２３０８の処理が終了すると、プロセッサ処理が終了する。
　また、ステップＳ２３０６において、新セッション鍵が正しいと判定された場合、処理はステップＳ２３０９に進む。ステップＳ２３０９において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、現在のセッション鍵を用いたePH2[TBD] = 1'b1のVC1フレームエンドを受信したか否かを判定する。受信していないと判定された場合、処理はステップＳ２３０６に戻り、それ以降の処理を繰り返す。
　また、ステップＳ２３０９において、ePH2[TBD] = 1'b1のVC1フレームエンドを受信したと判定された場合、処理はステップＳ２３１０に進む。ステップＳ２３１０において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を用いたePH2[TBD] = 1'b0のVC1フレームスタートを受信したか否かを判定し、受信したと判定されるまで待機する。受信したと判定された場合、処理はステップＳ２３１１に進む。
　ステップＳ２３１１において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、古いセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２３１２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の本使用を開始する。
　ステップＳ２３１２の処理が終了するとプロセッサ処理が終了する。
　図１９１のフローチャートを参照して、この場合のセンサ処理の流れの例を説明する。このセンサ処理は、図１９０のプロセッサ処理に対応する処理である。
　センサ処理が開始されると、ステップＳ２３５１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、図１９０のステップＳ２３０２においてアプリケーションプロセッサ１２１２から送信されたVC1鍵更新命令を受信したか否かを判定し、受信したと判定されるまで待機する。VC1鍵更新命令を受信したと判定された場合、処理はステップＳ２３５２に進む。
　ステップＳ２３５２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を導出する。
　ステップＳ２３５３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1埋込データを送信するか否かを判定し、送信すると判定されるまで待機する。送信すると判定された場合、処理はステップＳ２３５４に進む。
　ステップＳ２３５４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1第１埋込データをアプリケーションプロセッサ１２１２に送信する。
　ステップＳ２３５５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を仮使用したVC1第２埋込データを送信する。このVC1第２埋込データは、ステップＳ２３０４においてアプリケーションプロセッサ１２１２により受信される。
　ステップＳ２３５６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、ステップＳ２３０８においてアプリケーションプロセッサ１２１２から送信されたセッション鍵の継続命令を受信したか否かを判定する。受信したと判定された場合、処理はステップＳ２３５７に進む。この場合、セッション鍵の更新が中止され、現在のセッション鍵の使用が継続される。そこで、ステップＳ２３５７において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の破棄またはクリーンアップを開始する。ステップＳ２３５７の処理が終了するとセンサ処理が終了する。
　また、ステップＳ２３５６においてセッション鍵の継続命令を受信していないと判定された場合、処理はステップＳ２３５８に進む。ステップＳ２３５８において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1フレームエンドを送信するか否かを判定する。送信すると判定された場合、処理はステップＳ２３５９に進む。ステップＳ２３５９において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、ePH2[TBD] = 1'b1でVC1フレームエンドを送信する。このVC1フレームエンドは、ステップＳ２３０９においてアプリケーションプロセッサ１２１２により受信される。
　ステップＳ２３５９の処理が終了すると、処理はステップＳ２３６０に進む。また、ステップＳ２３５８においてVC1フレームエンドを送信しないと判定された場合、処理はステップＳ２３６０に進む。
　ステップＳ２３６０において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1フレームスタートを送信するか否かを判定する。送信しないと判定された場合、処理はステップＳ２３５６に戻り、それ以降の処理を繰り返す。
　また、ステップＳ２３６０において、VC1フレームスタートを送信すると判定された場合、処理はステップＳ２３６１に進む。ステップＳ２３６１において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、古いセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２３６２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の本使用を開始する。
　ステップＳ２３６３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、ePH2[TBD] = 1'b0でVC1フレームスタートを送信する。このVC1フレームスタートは、ステップＳ２３１０においてアプリケーションプロセッサ１２１２により受信される。
　ステップＳ２３６３の処理が終了するとセンサ処理が終了する。
　アプリケーションプロセッサ１２１２が上述のようにプロセッサ処理を行い、イメージセンサ１２１１が上述のようにセンサ処理を行うことにより、図１８９のフローチャートのように、新セッション鍵の検証を行うことができる。
　　＜新セッション鍵使用開始タイミング指定の省略＞
　新セッション鍵の使用開始タイミング指定を省略し、新セッション鍵を検証してもよい。新セッション鍵を仮使用して拡張パケットを検証してもよい。例えば、新セッション鍵を仮使用して拡張パケットのMAC値または復号を検証し、その検証結果がFAILの場合には本使用しているセッション鍵によって拡張パケットのMAC値または復号を検証する。そして、その検証結果もFAILな場合、END_SESSION要求を送信し、新セッション鍵およびセッション鍵を破棄またはクリーンアップすることによってセッションを終了させる。新セッション鍵が正しく導出されていると判断できる場合、セッション鍵の破棄またはクリーンアップを開始し、新セッション鍵の本使用を開始する。
　この場合のプロセッサ処理の流れの例を図１９２のフローチャートを参照して説明する。プロセッサ処理が開始されると、ステップＳ２４０１において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新が必要であるか否かを判定し、必要になるまで待機する。VC1鍵更新が必要であると判定された場合、処理はステップＳ２４０２に進む。
　ステップＳ２４０２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新命令を送信する。また、ステップＳ２４０３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を導出する。
　ステップＳ２４０４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1拡張パケットを受信したか否かを判定し、受信したと判定されるまで待機する。受信したと判定された場合、処理はステップＳ２４０５に進む。
　ステップＳ２４０５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を仮使用してそのVC1拡張パケットを検証する。ステップＳ２４０６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、その検証結果に基づいて、新セッション鍵が正しいか否かを判定する。
　新セッション鍵が正しいと判定された場合、処理はステップＳ２４０７に進む。ステップＳ２４０７において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、古いセッション鍵の破棄またはクリーンアップを開始する。そして、ステップＳ２４０８において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の本使用を開始する。ステップＳ２４０８の処理が終了するとプロセッサ処理が終了する。
　また、ステップＳ２４０６において新セッション鍵が正しくないと判定された場合、処理はステップＳ２４０９に進む。ステップＳ２４０９において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、現在のセッション鍵を使用してVC1拡張パケットを検証する。
　ステップＳ２４１０において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、その検証結果がFAILか否かを判定する。検証結果がFAILでないと判定された場合、処理はステップＳ２４０４に戻り、それ以降の処理を繰り返す。
　ステップＳ２４１０において検証結果がFAILであると判定された場合、処理はステップＳ２４１１に進む。ステップＳ２４１１において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、END_SESSION要求を送信する。そして、ステップＳ２４１２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵とともに現在のセッション鍵を破棄またはクリーンアップする。これにより、セッションが終了する。ステップＳ２４１２の処理が終了するとプロセッサ処理が終了する。
　図１９３のフローチャートを参照して、この場合のセンサ処理の流れの例を説明する。このセンサ処理は、図１９２のプロセッサ処理に対応する処理である。
　センサ処理が開始されると、ステップＳ２４５１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、図１９２のステップＳ２４０２においてアプリケーションプロセッサ１２１２から送信されたVC1鍵更新命令を受信したか否かを判定し、受信したと判定されるまで待機する。VC1鍵更新命令を受信したと判定された場合、処理はステップＳ２４５２に進む。
　ステップＳ２４５２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を導出する。
　ステップＳ２４５３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1拡張パケットを送信するか否かを判定し、送信すると判定されるまで待機する。送信すると判定された場合、処理はステップＳ２４５４に進む。
　ステップＳ２４５４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２４５５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の使用を開始する。
　ステップＳ２４５６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1拡張パケットを送信する。このVC1拡張パケットは、ステップＳ２４０４においてアプリケーションプロセッサ１２１２により受信される。
　ステップＳ２４５６の処理が終了するとセンサ処理が終了する。
　アプリケーションプロセッサ１２１２が上述のようにプロセッサ処理を行い、イメージセンサ１２１１が上述のようにセンサ処理を行うことにより、新セッション鍵を検証することができる。
　この例は、新セッション鍵が正しく導出されていることをプロセッサが検証する一例である。このようにすることで、プロセッサ処理は重たくなるが、センサ処理は軽くなるので、センサのリソースがプロセッサのリソースよりも限られる場合に好適である。
　なお、ラインMACに好適な構成例を図示しているが、一部（例えば、VC1拡張パケットを受信した）を変更することによってフレームMACに好適な構成例とすることが可能である。また、使用開始タイミング指定を併用してもよい。
　　＜プロセッサからの指示に応じたセッション鍵の選択＞
　センサは、プロセッサからの指示に応じてセッション鍵を選択してもよい。例えば、イメージセンサが新セッション鍵を仮使用して拡張パケット（被検証データ）を送信し、プロセッサによる拡張パケット検証結果に応じてセッション鍵の再使用を開始してもよい。
　また、プロセッサは、拡張パケットの検証結果に応じてセッション鍵不要命令または新セッション鍵不要命令を送信するようにしてもよい。これに対して、イメージセンサは、セッション鍵不要命令または新セッション鍵不要命令に応じて、新セッション鍵の本使用を開始するのか、セッション鍵の再使用を開始するのか、を選択してもよい。イメージセンサがセッション鍵または新セッション鍵を選択できるのであれば、セッション鍵不要命令および新セッション鍵不要命令は、別命令であってもよい。
　その場合のセンサ処理の流れの例を図１９４のフローチャートを参照して説明する。センサ処理が開始されると、ステップＳ２５０１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1鍵更新命令を受信したか否かを判定し、受信したと判定されるまで待機する。VC1鍵更新命令を受信したと判定された場合、処理はステップＳ２５０２に進む。
　ステップＳ２５０２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を導出する。
　ステップＳ２５０３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1拡張パケットを送信するか否かを判定し、送信すると判定されるまで待機する。送信すると判定された場合、処理はステップＳ２５０４に進む。
　ステップＳ２５０４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を仮使用してVC1拡張パケットを送信する。
　ステップＳ２５０５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、現在のセッション鍵不要命令を受信したか否かを判定する。受信したと判定された場合、処理はステップＳ２５０６に進む。この場合、セッション鍵
が更新される。
　ステップＳ２５０６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２５０７において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の本使用を開始する。ステップＳ２５０７の処理が終了するとセンサ処理が終了する。
　また、ステップＳ２５０５において、現在のセッション鍵不要命令を受信していないと判定された場合、処理はステップＳ２５０８に進む。
　ステップＳ２５０８において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵不要命令を受信したか否かを判定する。受信していないと判定された場合、処理はステップＳ２５０３に戻り、それ以降の処理を繰り返す。
　また、ステップＳ２５０８において、新セッション鍵不要命令を受信したと判定された場合、処理はステップＳ２５０９に進む。
　ステップＳ２５０９において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２５１０において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、現在のセッション鍵の再使用を開始する。ステップＳ２５１０の処理が終了するとセンサ処理が終了する。
　このようにセンサ処理を行うことにより、イメージセンサ１２１１は、アプリケーションプロセッサ１２１２から供給されるセッション鍵不要命令または新セッション鍵不要命令に応じて、新セッション鍵の本使用を開始するのか、セッション鍵の再使用を開始するのか、を選択することができる。
　　＜KeyUpdateReq、KeySwitchTimingの利用＞
　例えば、図１９５に示されるように、KeyUpdateReqやKeySwitchTimingを利用して新セッション鍵の使用開始タイミングを指定するようにしてもよい。
　KeyUpdateReqまたはKeySwitchTimingは、例えば埋込データ内に格納されて送信される。ただし、KeyUpdateReqまたはKeySwitchTimingは、画像データ内、ユーザ定義データ内、読み出し応答（帯域内割込み含む）内、の何れかに格納されて送信されてもよい。また、KeyUpdateReqまたはKeySwitchTimingのField名、Bits割り当て、Value定義などの何れかが異なってもよい。また、KeyUpdateReqはCCIホストによるKEY_UPDATE要求メッセージをトリガするために送信されるが、KeyUpdateReqの送信を不要にしてもよい。その場合、CSI-2デバイスではなくCSI-2ホストまたはCCIホストが、KEY_UPDATE要求メッセージをトリガする。また、GET_ENCAPSULATED_REQUESTメカニズムを用いる場合、CSI-2デバイスがCCIデバイスによるKEY_UPDATE要求メッセージをトリガしてもよい。また、第2埋込データの送信と新セッション鍵の検証とを不要にしてもよい。
　KeyUpdateReqやKeySwitchTimingを用いる場合の処理の流れの例を図１９６のフローチャートを参照して説明する。CSI-2ホストがステップＳ２６０１においてセッション鍵を導出し、CSI-2デバイスがステップＳ２６２１においてセッション鍵を導出する。その後、そのセッション鍵（現在のセッション鍵）を用いて通信が行われる。CSI-2デバイスは現在のセッション鍵を用いてVC1拡張パケットを送信し（ステップＳ２６２２）、CSI-2ホストはそれを受信する（ステップＳ２６０２）。以降の通信は同様に行われる。
　その後、所定のタイミングにおいて、CSI-2デバイスは、ステップＳ２６２３において、現在のセッション鍵を用いてKeyUpdataReqが格納された埋込データを送信する。CSI-2ホストは、ステップＳ２６０３において、それを受信する。
　そして、CSI-2ホストおよびCSI-2デバイスは、それぞれ新セッション鍵を導出する（Ｓ２６０４、Ｓ２６２４）。
　ステップＳ２６２５において、CSI-2デバイスは、現在のセッション鍵を用いてVC1第１埋込データを送信する。ステップＳ２６０５において、CSI-2ホストは、それを受信する。
　そして、ステップＳ２６２６において、CSI-2デバイスは、新セッション鍵を仮使用してVC1第２埋込データを送信する。ステップＳ２６０６において、CSI-2ホストは、それを受信する。ステップＳ２６０７において、CSI-2ホストは、新セッション鍵を検証する。
　新セッション鍵が正しく導出された判定された場合、指定されたタイミングにおいて、セッション鍵の更新が行われる。つまり、新セッション鍵の使用が開始される。
　そのため、ステップＳ２６２７において、CSI-2デバイスは、現在のセッション鍵を用いて、KeySwitchiming = 1'b1を送信する。ステップＳ２６０８において、CIS-2ホストは、それを受信する。
　ステップＳ２６２９において、CSI-2デバイスは、新セッション鍵を本使用してVC1フレームスタートを送信する。ステップＳ２６０９において、CSI-2ホストは、それを受信する。
　ステップＳ２６３０において、CSI-2デバイスは、新セッション鍵を本使用してVC1拡張パケットを送信する。ステップＳ２６１１において、CSI-2ホストは、それを受信する。以降の通信は同様に行われる。
　なお、所定のタイミングにおいて、CSI-2ホストおよびCSI-2デバイスは、それぞれ、更新前のセッション鍵（古いセッション鍵）を破棄する（Ｓ２６１０、Ｓ２６２８）。
　このようにすることにより、KeyUpdateReqやKeySwitchTimingを利用して新セッション鍵の使用開始タイミングを指定することができる。
　この場合のプロセッサ処理の流れの例を図１９７のフローチャートを参照して説明する。プロセッサ処理が開始されると、ステップＳ２６５１において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新が必要であるか否かを判定し、必要になるまで待機する。VC1鍵更新が必要であると判定された場合、処理はステップＳ２６５２に進む。
　ステップＳ２６５２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新命令を送信する。また、ステップＳ２６５３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を導出する。
　ステップＳ２６５４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、KeySwitchTiming = 1'b1のVC1第１埋込データを受信したか否かを判定し、受信したと判定されるまで待機する。受信したと判定された場合、処理はステップＳ２６５５に進む。
　ステップＳ２６５５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を仮使用した第２埋込データを検証する。そして、ステップＳ２６５６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、その検証結果に基づいて、新セッション鍵が正しいか否かを判定する。新セッション鍵が正しくないと判定された場合、処理はステップＳ２６５７に進む。
　ステップＳ２６５７において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の破棄またはクリーンアップを開始する。ステップＳ２６５８において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、現在のセッション鍵の継続命令を送信する。ステップＳ２６５８の処理が終了すると、プロセッサ処理が終了する。
　また、ステップＳ２６５６において、新セッション鍵が正しいと判定された場合、処理はステップＳ２６５９に進む。ステップＳ２６５９において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1フレームスタートを受信したか否かを判定する。受信していないと判定された場合、処理はステップＳ２６５６に戻り、それ以降の処理を繰り返す。
　また、ステップＳ２６５９において、VC1フレームスタートを受信したと判定された場合、処理はステップＳ２６６０に進む。ステップＳ２６６０において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２６６１において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の本使用を開始する。ステップＳ２６６１の処理が終了するとプロセッサ処理が終了する。
　図１９８のフローチャートを参照して、この場合のセンサ処理の流れの例を説明する。このセンサ処理は、図１９７のプロセッサ処理に対応する処理である。
　センサ処理が開始されると、ステップＳ２６８１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、図１９７のステップＳ２６５２においてアプリケーションプロセッサ１２１２から送信されたVC1鍵更新命令を受信したか否かを判定し、受信したと判定されるまで待機する。VC1鍵更新命令を受信したと判定された場合、処理はステップＳ２６８２に進む。
　ステップＳ２６８２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を導出する。
　ステップＳ２６８３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1埋込データを送信するか否かを判定し、送信すると判定されるまで待機する。送信すると判定された場合、処理はステップＳ２６８４に進む。
　ステップＳ２６８４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、KeySwitchTiming=1'b1でVC1第１埋込データを送信する。
　ステップＳ２６８５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を仮使用したVC1第２埋込データを送信する。
　ステップＳ２６８６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、ステップＳ２６５８においてアプリケーションプロセッサ１２１２から送信されたセッション鍵の継続命令を受信したか否かを判定する。受信したと判定された場合、処理はステップＳ２６８７に進む。ステップＳ２６８７において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の破棄またはクリーンアップを開始する。ステップＳ２６８７の処理が終了するとセンサ処理が終了する。
　また、ステップＳ２６８６においてセッション鍵の継続命令を受信していないと判定された場合、処理はステップＳ２６８８に進む。ステップＳ２６８８において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1フレームスタートを送信するか否かを判定する。送信しないと判定された場合、処理はステップＳ２６８６に戻り、それ以降の処理を繰り返す。
　また、ステップＳ２６８８において、VC1フレームスタートを送信すると判定された場合、処理はステップＳ２６８９に進む。ステップＳ２６８９において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２６９０において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の本使用を開始する。ステップＳ２６９０の処理が終了するとセンサ処理が終了する。
　アプリケーションプロセッサ１２１２が上述のようにプロセッサ処理を行い、イメージセンサ１２１１が上述のようにセンサ処理を行うことにより、図１９６のフローチャートのように、新セッション鍵の検証を行うことができる。
　なお、センサまたはプロセッサが追加メッセージカウンタを備える場合、新セッション鍵の使用または本使用（仮使用を除く）を開始する際に、追加メッセージカウント値を初期化して０に設定する。ただし、その場合、メッセージカウント値は初期化しないことが望ましい。
　さらに新セッション鍵を仮使用する場合、例えば、追加メッセージカウント値を最大値に設定して新セッション鍵を仮使用してもよい。または例えば、追加メッセージカウント値を０に設定して新セッション鍵を仮使用し、新セッション鍵の本使用を開始する際に、追加メッセージカウント値を１に設定してもよい。
　これに対して、メッセージカウント値が初期値（例えば、０）になるタイミングで新セッション鍵の使用または本使用（仮使用を除く）を開始してもよい。その場合、新セッション鍵を使用できる回数が最大になる。
　また、センサまたはプロセッサが追加フレームカウンタを備える場合、新セッション鍵の使用または本使用（仮使用を除く）を開始する際に、追加フレームカウント値を初期化して０に設定する。
　ただし、その場合、フレームカウント値は初期化しないことが望ましい。さらに新セッション鍵を仮使用する場合、例えば、追加フレームカウント値を最大値に設定して新セッション鍵を仮使用してもよい。または例えば、追加フレームカウント値を０に設定して新ッション鍵を仮使用し、新セッション鍵の本使用を開始する際に、追加フレームカウン
ト値を１に設定してもよい。
　これに対して、フレームカウント値が初期値（例えば、１）になるタイミングで新セッション鍵の使用または本使用（仮使用を除く）を開始してもよい。その場合、新セッション鍵を使用できる回数が最大になる。
　　＜埋込データや読み出し応答による新セッション鍵の使用開始タイミング指定＞
　埋込データや読み出し応答によって新セッション鍵の使用開始タイミングを指定してもよい。使用開始タイミングを指定するメッセージ（使用開始タイミング指定）は、埋込データ内または画像データ内またはユーザ定義データ内または読み出し応答（帯域内割込み含む）内に格納されて送信されてもよい。使用開始タイミング指定は、メッセージカウント値（メッセージカウンタの値）を含んでもよい。その場合、使用開始タイミングとして指定されたメッセージカウント値の拡張パケットの一部または全部から、新セッション鍵の使用が開始されてもよい。また、使用開始タイミング指定は、フレーム番号（フレームカウント値）を含んでもよい。その場合、使用開始タイミングとして指定されたフレーム番号の拡張パケットの一部または全部から、新セッション鍵の使用が開始されてもよい。また、使用開始タイミング指定は、eDT（拡張データタイプ）またはDT（データタイプ）の値を含んでもよい。その場合、次のライン以降に送信される、使用開始タイミングとして指定されたeDTまたはDTの拡張パケットの一部または全部から、新セッション鍵の使用が開始されてもよい。
　この場合のプロセッサ処理の流れの例を、図１９９のフローチャートを参照して説明する。プロセッサ処理が開始されると、ステップＳ２７０１において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新が必要であるか否かを判定し、必要になるまで待機する。VC1鍵更新が必要であると判定された場合、処理はステップＳ２７０２に進む。
　ステップＳ２７０２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新命令を送信する。また、ステップＳ２７０３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を導出する。
　ステップＳ２７０４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、タイミング指定を受信したか否かを判定し、受信したと判定されるまで待機する。タイミング指定を受信したと判定された場合、処理はステップＳ２７０５に進む。
　ステップＳ２７０５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、タイミング指定のVC1拡張パケットヘッダを受信したか否かを判定し、受信したと判定されるまで待機する。タイミング指定のVC1拡張パケットヘッダを受信したと判定された場合、処理はステップＳ２７０６に進む。
　ステップＳ２７０６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２７０７において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の使用を開始する。
　ステップＳ２７０７の処理が終了するとプロセッサ処理が終了する。
　図２００のフローチャートを参照して、イメージセンサ１２１１の処理であるセンサ処理の流れの例を説明する。このセンサ処理は、図１９９のプロセッサ処理に対応する処理である。
　センサ処理が開始されると、ステップＳ２７２１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1鍵更新命令を受信したか否かを判定し、受信したと判定されるまで待機する。VC1鍵更新命令を受信したと判定された場合、処理はステップＳ２７２２に進む。
　ステップＳ２７２２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を導出する。
　ステップＳ２７２３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1埋込データを送信するか否かを判定し、送信すると判定されるまで待機する。VC1埋込データを送信すると判定された場合、処理はステップＳ２７２４に進む。
　ステップＳ２７２４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、使用開始タイミング指定を含むVC1埋込データを送信する。
　ステップＳ２７２５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、タイミング指定のVC1拡張パケットヘッダを送信するか否かを判定し、送信すると判定されるまで待機する。タイミング指定のVC1拡張パケットヘッダを送信すると判定された場合、処理はステップＳ２７２６に進む。
　ステップＳ２７２６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２７２７において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の使用を開始する。
　ステップＳ２７２７の処理が終了するとセンサ処理が終了する。
　アプリケーションプロセッサ１２１２が上述のようにプロセッサ処理を行い、イメージセンサ１２１１が上述のようにセンサ処理を行うことにより、埋込データや読み出し応答によって新セッション鍵の使用開始タイミングを指定することができる。
　　＜書き込み命令による新セッション鍵の使用開始タイミング指定＞
　書き込み命令によって、プロセッサが、新セッション鍵の使用開始タイミングを指定してもよい。つまり、使用開始タイミングを指定するメッセージ（使用開始タイミング指定）は、書き込み命令内に格納されて送信されてもよい。使用開始タイミング指定は、メッセージカウント値（メッセージカウンタの値）を含んでもよい。その場合、使用開始タイミングとして指定されたメッセージカウント値の拡張パケットの一部または全部から、新セッション鍵の使用が開始されてもよい。また、使用開始タイミング指定は、フレーム番号（フレームカウント値）を含んでもよい。その場合、使用開始タイミングとして指定されたフレーム番号の拡張パケットの一部または全部から、新セッション鍵の使用が開始されてもよい。また、使用開始タイミング指定は、eDT（拡張データタイプ）またはDT（データタイプ）の値を含んでもよい。その場合、使用開始タイミング指定でOKの読み出し応答以降に送信される、使用開始タイミングとして指定されたeDTまたはDTの拡張パケットの一部または全部から、新セッション鍵の使用が開始されてもよい。
　この場合のプロセッサ処理の流れの例を、図２０１のフローチャートを参照して説明する。プロセッサ処理が開始されると、ステップＳ２７４１において、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新が必要であるか否かを判定し、必要になるまで待機する。VC1鍵更新が必要であると判定された場合、処理はステップＳ２７４２に進む。
　ステップＳ２７４２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、VC1鍵更新命令を送信する。また、ステップＳ２７４３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵を導出する。
　ステップＳ２７４４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、使用開始タイミング指定を含む書き込み命令を送信する。
　ステップＳ２７４５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、使用開始タイミング指定の可否の読み出し命令を送信する。
　ステップＳ２７４６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、読み出し応答を受信したか否かを判定し、受信したと判定されるまで待機する。読み出し応答を受信したと判定された場合、処理はステップＳ２７４７に進む。
　ステップＳ２７４７において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、使用開始タイミング指定でＯＫの応答か否かを判定する。使用開始タイミングでＯＫの応答でない場合、処理はステップＳ２７４４に戻り、それ以降の処理を繰り返す。
　また、ステップＳ２７４７において、使用開始タイミング指定でＯＫの応答であると判定された場合、処理はステップＳ２７４８に進む。
　ステップＳ２７４８において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、タイミング指定のVC1拡張パケットヘッダを受信したか否かを判定し、受信したと判定されるまで待機する。タイミング指定のVC1拡張パケットヘッダを受信したと判定された場合、処理はステップＳ２７４９に進む。
　ステップＳ２７４９において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２７５０において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、新セッション鍵の使用を開始する。
　ステップＳ２７５０の処理が終了するとプロセッサ処理が終了する。
　図２０２のフローチャートを参照して、イメージセンサ１２１１の処理であるセンサ処理の流れの例を説明する。このセンサ処理は、図２０１のプロセッサ処理に対応する処理である。
　センサ処理が開始されると、ステップＳ２７７１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、VC1鍵更新命令を受信したか否かを判定し、受信したと判定されるまで待機する。VC1鍵更新命令を受信したと判定された場合、処理はステップＳ２７７２に進む。
　ステップＳ２７７２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵を導出する。
　ステップＳ２７７３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、書き込み命令を受信したか否かを判定し、受信したと判定されるまで待機する。書き込み命令を受信したと判定された場合、処理はステップＳ２７７４に進む。
　ステップＳ２７７４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、読み出し命令を受信したか否かを判定し、受信したと判定されるまで待機する。読み出し命令を受信したと判定された場合、処理はステップＳ２７７５に進む。
　ステップＳ２７７５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、使用開始タイミング指定でＯＫか否かを判定する。使用開始タイミングでＯＫでないと判定された場合、処理はステップＳ２７７６に進む。
　ステップＳ２７７６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、使用開始タイミング指定だとＮＧの読み出し応答を行う。ステップＳ２７７６の処理が終了すると処理はステップＳ２７７３に戻り、それ以降の処理を繰り返す。
　ステップＳ２７７５において、使用開始タイミングでＯＫであると判定された場合、処理はステップＳ２７７７に進む。
　ステップＳ２７７７において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、使用開始タイミング指定でＯＫの読み出し応答を行う。
　ステップＳ２７７８において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、タイミング指定のVC1拡張パケットヘッダを送信するか否かを判定し、送信すると判定されるまで待機する。タイミング指定のVC1拡張パケットヘッダを送信すると判定された場合、処理はステップＳ２７７９に進む。
　ステップＳ２７７９において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、現在のセッション鍵の破棄またはクリーンアップを開始する。
　ステップＳ２７８０において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、新セッション鍵の使用を開始する。
　ステップＳ２７８０の処理が終了するとセンサ処理が終了する。
　アプリケーションプロセッサ１２１２が上述のようにプロセッサ処理を行い、イメージセンサ１２１１が上述のようにセンサ処理を行うことにより、書き込み命令によって新セッション鍵の使用開始タイミングを指定することができる。
　　＜鍵ID情報による新セッション鍵の使用開始タイミング指定＞
　次セッション鍵（新セッション鍵）の使用開始に応じて更新（例えば、インクリメントまたはデクリメントまたは乱数）される鍵ID情報を送信することによって、次セッション鍵（新セッション鍵）の使用開始タイミングを指定してもよい。
　その場合のプロセッサ処理の流れの例を、図２０３を参照して説明する。プロセッサ処理が開始されると、アプリケーションプロセッサ１２１２の拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、ステップＳ２８０１において、鍵IDを０に初期化する。
　ステップＳ２８０２において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、セッション鍵の使用を開始する。
　ステップＳ２８０３において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、セッションを終了するか否かを判定する。終了すると判定された場合、処理はステップＳ２８０４に進む。
　ステップＳ２８０４において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、END_SESSION要求を送信する。
　ステップＳ２８０５において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、イメージセンサ１２１１から応答を受信したか否かを判定する。応答を受信していないと判定された場合、処理はステップＳ２８０４に戻り、それ以降の処理を繰り返す。ステップＳ２８０５において、応答を受信したと判定された場合、処理はステップＳ２８０６に進む。
　ステップＳ２８０６において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、全てのセッション鍵および次セッション鍵（新セッション鍵）を破棄またはクリーンアップする。ステップＳ２８０６の処理が終了するとプロセッサ処理が終了する。
　また、ステップＳ２８０３においてセッションを終了しないと判定された場合、処理はステップＳ２８０７に進む。
　ステップＳ２８０７において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、鍵ID情報を受信したか否かを判定する。受信していないと判定された場合、処理はステップＳ２８０３に戻り、それ以降の処理を繰り返す。ステップＳ２８０７において、鍵ID情報を受信したと判定された場合、処理はステップＳ２８０８に進む。
　ステップＳ２８０８において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、鍵ID情報が更新されているか否かを判定する。更新されていないと判定された場合、処理はステップＳ２８０３に戻り、それ以降の処理を繰り返す。ステップＳ２８０８において、鍵ID情報が更新されたと判定された場合、処理はステップＳ２８０９に進む。
　ステップＳ２８０９において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、次セッション鍵（新セッション鍵）の使用を開始する。
　ステップＳ２８１０において、拡張モード対応CSI-2受信回路１３２２および／またはセキュリティ部１３２６は、鍵IDを更新する。ステップＳ２８１０の処理が終了すると、処理はステップＳ２８０３に戻り、それ以降の処理を繰り返す。
　図２０４のフローチャートを参照して、イメージセンサ１２１１の処理であるセンサ処理の流れの例を説明する。このセンサ処理は、図２０３のプロセッサ処理に対応する処理である。
　センサ処理が開始されると、ステップＳ２８３１において、イメージセンサ１２１１の拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、鍵IDを０に初期化する。
　ステップＳ２８３２において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、セッション鍵の使用を開始する。
　ステップＳ２８３３において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、END_SESSION要求を受信したか否かを判定する。END_SESSION要求を受信していないと判定された場合、処理はステップＳ２８３４に進む。
　ステップＳ２８３４において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、次セッション鍵（新セッション鍵）の使用を開始するか否かを判定する。開始すると判定された場合、処理はステップＳ２８３５に進む。
　ステップＳ２８３５において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、次セッション鍵（新セッション鍵）の使用を開始する。
　ステップＳ２８３６において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、鍵IDを更新する。ステップＳ２８３６の処理が終了すると処理はステップＳ２８３７に進む。また、ステップＳ２８３４において、次セッション鍵（新セッション鍵）の使用を開始しないと判定された場合、処理はステップＳ２８３７に進む。
　ステップＳ２８３７において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、鍵ID情報を送信する。ステップＳ２８３７の処理が終了すると、処理はステップＳ２８３３に戻り、それ以降の処理を繰り返す。
　また、ステップＳ２８３３において、END_SESSION要求を受信したと判定された場合、処理はステップＳ２８３８に進む。
　ステップＳ２８３８において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、アプリケーションプロセッサ１２１２に対して応答を送信する。
　ステップＳ２８３９において、拡張モード対応CSI-2送信回路１３０４および／またはセキュリティ部１３１０は、全てのセッション鍵および次セッション鍵（新セッション鍵）を破棄またはクリーンアップする。
　ステップＳ２８３９の処理が終了するとセンサ処理が終了する。
　アプリケーションプロセッサ１２１２が上述のようにプロセッサ処理を行い、イメージセンサ１２１１が上述のようにセンサ処理を行うことにより、鍵ID情報によって新セッション鍵の使用開始タイミングを指定することができる。
　鍵ID情報は、鍵IDそのものの値であってもよいし、例えば図２０５に示されるように、今回に使用している鍵IDまたは次回に使用する鍵IDが偶数（Even key）なのか奇数（Odd key）なのかを示す情報であってもよい。また、鍵IDが、偶数（Even key）なのか奇数（Odd key）なのかを示す情報であってもよい。ただし、鍵ID情報は、０（偶数）と１（奇数）とのみで構成されてもよい。
　　＜複数セッション鍵の導出＞
　1つのExport Master Secretから複数のセッション鍵（暗号化鍵またはMAC鍵）を導出してもよい。例えば、仮想チャネル毎または拡張仮想チャネル毎にセッション鍵を異ならせたい場合に有効である。
　また、図２０６や図２０７に示される例のように、複数のExport Master Secret（0…N）を導出し、それぞれからセッション鍵（暗号化鍵またはMAC鍵）を導出してもよい。その場合、更新するExport Master Secretを指定することによって、一部のExport MasterSecretのみ更新されるようにしてもよい。HKDF-Expand内のExport-Master-Secret、bin_str8_1、…、bin_str8_N、などは一例であり、別の文字が格納されてもよい。
　HKDF-Expand、Hash.Length、bin_str3、bin_str4、bin_str8、BinConcat、Version、TH2、などの定義は非特許文献１に記載されている通りである。bin_str8_0、…、bin_str8_Nとしては、例えば、bin_str8 _0 = BinConcat(Hash.Length, Version, “exp master 0”, TH2); 、…、bin_str8 _N = BinConcat(Hash.Length, Version, “exp master N”,TH2);の定義が適用されるが、別の定義が適用されてもよい。
　ところで、例えばCCIホスト（制御系通信ホスト）とCCIデバイス（制御系通信デバイス）とで構成される制御系通信はControl Plane（Configuration, status, capabilities,not application data. Options include CCI out-of-band (I2C/I3C), USL in-band, and ACMD/ACMP using mailbox registers.）とも称する。例えばCSI-2ホスト（画像系通信ホスト）とCSI-2デバイス（画像系通信デバイス）とで構成される画像系通信はData Plane（Pixels, content, application data.）とも称する。また、制御系通信ホストと画像系通信ホストとは、一体であってもよいし、別体であってもよい。また、制御系通信デバイスと画像系通信デバイスとは、一体であってもよいし、別体であってもよい。また、画像系通信ホストがDSI-2ホストであって画像系通信デバイスがディスプレイ（DSI-2デバイス）である場合、図７８、図７９、図８０、図１８４、図１８６、図１８９、および図１９６などの画像系通信ホスト（図中ではCSI-2ホスト）と画像系通信デバイス（図中ではCSI-2デバイス）との間の矢印の方向は逆向きとなる。
　ところで、以上においては、画像系通信ホストと画像系通信デバイスとの間のセッション鍵または新セッション鍵が、SPDM鍵スケジュールから導出される例を用いて説明したが、本技術はその限りではない。例えば、制御系通信ホストかつ画像系通信ホストでもあるSSMC（Secure Session Manager Controller）またはアプリケーションプロセッサ（SoCまたはSystem on Chipとも称する）が生成し、制御系通信デバイスかつ画像系通信デバイスでもあるイメージセンサ、ディスプレイ、またはブリッジ（Bridge）一端と制御系通信ホストとの間の保護されたセッション（例えば、SPDMセッション）を介して制御系通信デバイスで受信された鍵が、画像系通信ホストと画像系通信デバイスとの間のセッション鍵または新セッション鍵として使用されてもよい。また、制御系通信ホストであるSSMCまたはアプリケーションプロセッサが生成し、制御系通信デバイスであるブリッジ一端、イメージセンサ、ディスプレイ、またはブリッジ他端と制御系通信ホストとの間の保護されたセッション（例えば、SPDMセッション）を介して制御系通信デバイスで受信された鍵が、画像系通信ホストであるアプリケーションプロセッサまたはブリッジ一端と画像系通信デバイスであるブリッジ一端（ただし、ブリッジ一端が画像系通信ホストではない場合）、イメージセンサ、ディスプレイ、またはブリッジ他端との間のセッション鍵または新セッション鍵として使用されてもよい。また、制御系通信ホストであるSSMCが生成し、制御系通信デバイスであるアプリケーションプロセッサ、ブリッジ一端、イメージセンサ、ディスプレイ、またはブリッジ他端と制御系通信ホストとの間の保護されたセッション（例えば、SPDMセッション）を介して制御系通信デバイスで受信された鍵が、画像系通信ホストであるアプリケーションプロセッサまたはブリッジ一端と画像系通信デバイスであるブリッジ一端（ただし、ブリッジ一端が画像系通信ホストではない場合）、イメージセンサ、ディスプレイ、またはブリッジ他端との間のセッション鍵または新セッション鍵として使用されてもよい。なお、SSMCとアプリケーションプロセッサの一部または全部とは、一体であってもよいし、別体であってもよい。また、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）を介した画像系通信向けセッション鍵または新セッション鍵の送信は、Vendor defined SPDMメッセージ（例えば、VENDOR_DEFINED_REQUEST要求メッセージまたはVENDOR_DEFINED_RESPONSE応答メッセージ）によって送信されてもよい。つまり、画像系通信ホストと画像系通信デバイスとの間のセッション鍵または新セッション鍵を制御系通信ホストが生成する場合、制御系通信デバイスはExport Master Secretを導出する必要はなく、図１８４におけるKEY_UPDATE要求およびKEY_UPDATE_ACK応答は省略されることが可能である。また、制御系通信ホストは、画像系通信ホストと画像系通信デバイスとの間のセッション鍵または新セッション鍵を、Export Master Secretからの導出によって生成してもよいし、Export Master Secretとは異なるシークレットからの導出によって生成してもよいし、真性乱数生成器または疑似乱数生成器から生成してもよいし、これらとは異なる手段を用いて生成してもよい。また、画像系通信ホストと画像系通信デバイスとの間のセッション鍵または新セッション鍵は、第１画像系通信ホストと第１画像系通信デバイスと第２画像系通信ホストまたは第２画像系通信デバイスとの間（３つ以上の間）で使用可能なグループ鍵であってもよい。つまり、画像系通信ホストまたは画像系通信デバイスは、unicast（one-to-one）送信または受信だけではなく、multicast（one-to-many）送信または受信に対応してもよい。
　ところで、制御系通信ホストと画像系通信ホストとが別体である場合、画像系通信向けセッション鍵または新セッション鍵の使用開始タイミングに課題がある。例えば、画像系通信ホストがアプリケーションプロセッサまたはブリッジ一端であって画像系通信デバイスがイメージセンサまたはブリッジ他端である場合、画像系通信ホストであるアプリケーションプロセッサまたはブリッジ一端で画像系通信向けセッション鍵または新セッション鍵が受信されているのか（使用開始できるのか）イメージセンサまたはブリッジ他端には分からないという問題がある。これは、制御系通信ホストが、画像系通信向けセッション鍵または新セッション鍵を画像系データ受信側である制御系通信デバイス（例えば、イメージセンサに対応するアプリケーションプロセッサ、ディスプレイ、ブリッジ一端）へ先に送信し、その後に画像系データ送信側である制御系通信デバイス（例えば、イメージセンサ、ディスプレイに対応するアプリケーションプロセッサ、ブリッジ一端（ただし、ブリッジ一端が画像系データ受信側ではない場合）、ブリッジ他端）へ同じセッション鍵または同じ新セッション鍵を送信することによって解決できる。または、画像系通信向けセッション鍵または新セッション鍵の使用開始タイミングを制御系通信ホストが管理し、画像系通信向けセッション鍵または新セッション鍵を使用開始できることを示す情報が、制御系通信ホストから画像系データ送信側である制御系通信デバイスへ送信され、その受信に応じて画像系データ送信側が画像系通信向けセッション鍵または新セッション鍵を使用開始することによって解決できる。
　ところで、第１通信（例えば、制御系通信）と第１通信よりも高速な第２通信（例えば、画像系通信）とを保護する保護部は、第１セキュリティ演算部と第２セキュリティ演算部とを含んで構成されてもよい。また、第１セキュリティ演算部と第２セキュリティ演算部とは、同じ暗号アルゴリズムが適用されてもよいし、それぞれ異なる暗号アルゴリズムが適用されてもよい。例えば、画像系通信向けとして第１セキュリティ演算部にAES-GCM、AES-GMAC、ブロック暗号CCMモード、HMAC、またはCMACの何れかが適用され、制御系通信向けとして第２セキュリティ演算部にブロック暗号CBC（Cipher Block Chaining）モードまたはブロック暗号CTR（Counter）モードの何れかとHMACまたはCMACの何れかとの組み合わせが適用されてもよい。また、画像系通信向けとして第１セキュリティ演算部にブロック暗号CBCモードまたはブロック暗号CTRモードの何れかとHMACまたはCMACの何れかとの組み合わせが適用されてもよく、制御系通信向けとして第２セキュリティ演算部にAES-GCMまたはブロック暗号CCMモードの何れかが適用されてもよい。つまり、画像系通信ホストと画像系通信デバイスとの間の保護されたセッション（例えば、非SPDMセッション）は少なくともメッセージ認証によって保護されていればよいが、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）を介したセッション鍵または新セッション鍵の送信は、暗号化およびメッセージ認証によって保護される必要がある。ただし、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）内であっても、セッション鍵または新セッション鍵に関わらないメッセージは、暗号化しないでメッセージ認証によって保護されてもよいし、暗号化およびメッセージ認証によって保護されてもよい。例えば、Vendor defined SPDMメッセージ（例えば、VENDOR_DEFINED_REQUEST要求メッセージまたはVENDOR_DEFINED_RESPONSE応答メッセージ）の一部または全部が暗号化およびメッセージ認証によって保護され、HEARTBEAT要求メッセージ、HEARTBEAT_ACK応答メッセージ、HEARTBEAT_NAK応答メッセージ、ERROR応答メッセージ、KEY_UPDATE要求、KEY_UPDATE_ACK応答、またはVendor defined SPDMメッセージの残りなどが暗号化しないでメッセージ認証によって保護されてもよいし、暗号化およびメッセージ認証によって保護されてもよい。また、制御系通信ホストから制御系通信デバイスへ送信されるメッセージが暗号化およびメッセージ認証によって保護され、制御系通信デバイスから制御系通信ホストへ送信されるメッセージが暗号化しないでメッセージ認証によって保護されてもよいし、暗号化およびメッセージ認証によって保護されてもよい。
　ところで、図１５９は、拡張パケットヘッダ内のService Descriptorがメッセージ認証ON/OFF（Enable/Disable）のbitフラグを含む場合を示しているが、このbitフラグは攻撃者によって改竄される可能性がある。つまり、攻撃者によって画像系通信におけるメッセージ認証が無効化されるリスクがある。また、拡張パケットヘッダ内のService Descriptorが、メッセージ認証ON/OFFのbitフラグではなく、メッセージ認証を含むセキュリティ機能ON/OFFのbitフラグを含む場合にも同様である。また、例えば、ePH2[27:25]=ServiceDescriptor[3:1]=0b000：メッセージ認証なし・暗号化なし（セキュリティ機能が無効）、ePH2[27:25]=Service Descriptor[3:1]=0b001：メッセージ認証あり・暗号化あり（セキュリティ機能が有効）、ePH2[27:25]=Service Descriptor[3:1]=0b010：メッセージ認証あり・暗号化なし（セキュリティ機能が有効）、と定義してもよい。ただし、これらのビット割り当てや表現は異なってもよい。しかしながら、このリスクを承知した上で実装者が画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の有効化と無効化とを切り替える場合がある。その場合、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を許可するか否かを示す情報（例えば、1'b1：メッセージ認証またはメッセージ認証を含むセキュリティ機能のServiceDescriptorによる無効化を許可する、1'b0：メッセージ認証またはメッセージ認証を含むセキュリティ機能のService Descriptorによる無効化を許可しない）が、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）を介して制御系通信ホストから制御系通信デバイスへ送信されることが望ましい。ただし、これらのビット割り当て（1'b1/1'b0）は、逆に割り当てられてもよいし、1ビットの領域ではなく2ビット以上の領域に割り当てられてもよい。攻撃者によって画像系通信におけるメッセージ認証が無効化されるリスクを許容できない他の実装者は、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を許可しないことによって、攻撃者によって画像系通信におけるメッセージ認証が無効化（改竄）されることを対策できる。つまり、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を許可するか否かを示す情報（無効化に関連する情報）は、画像系通信が開始（例えば、画像系通信の拡張パケットが送信または受信）される前に、制御系通信向けセッション鍵によって保護された制御系通信を利用して（例えば、他パラメータ情報の一部または全部として）制御系通信ホストから送信または制御系通信デバイスで受信され、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の一部または全部の無効化または有効化を示す情報は、画像系通信の拡張パケット（例えば、拡張パケットヘッダ、Service Descriptor、パケットデータ）内に格納されて画像系データ受信側で受信または画像系データ送信側から送信されてもよい。また、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を許可するか否かを示す情報（無効化に関連する情報）は、画像系通信向けセッション鍵または新セッション鍵の使用が画像系データ送信側で開始される前に、制御系通信向けセッション鍵によって保護された制御系通信を利用して（例えば、他パラメータ情報の一部または全部として）制御系通信ホストから送信または制御系通信デバイスで受信され、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の一部または全部の無効化または有効化を示す情報は、画像系通信向けセッション鍵または新セッション鍵の画像系データ送信側における使用開始に応じて（または使用が画像系データ送信側で開始された後に）、画像系通信の拡張パケット（例えば、拡張パケットヘッダ、Service Descriptor、パケットデータ）内に格納されて画像系データ受信側で受信または画像系データ送信側から送信されてもよい。ただし、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を許可するか否かを示す情報（無効化に関連する情報）の送信または受信は、画像系通信ホストと画像系通信デバイスとの間の事前合意（Private contract）で代用されてもよい。つまり、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の一部または全部の無効化または有効化を示す情報は、事前合意された情報に従って画像系通信の拡張パケット（例えば、拡張パケットヘッダ、Service Descriptor、パケットデータ）内に格納されて画像系データ送信側から送信され、画像系データ受信側で受信され、事前合意された情報と受信された情報とが異なる場合、画像系データ受信側は拡張パケットが改竄されたと判断してもよい。一方、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能を有効化することは、許可されてもよい。つまり、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の一部または全部の有効化を示す情報は、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を示す情報が画像系通信の拡張パケット（例えば、拡張パケットヘッダ、ServiceDescriptor、パケットデータ）内に格納されて画像系データ送信側から送信または画像系データ受信側で受信された後に、画像系通信向けセッション鍵または新セッション鍵の画像系データ送信側における使用開始に応じて（または使用が画像系データ送信側で開始された後に）、画像系通信の拡張パケット（例えば、拡張パケットヘッダ、Service Descriptor、パケットデータ）内に格納されて画像系データ送信側から送信または画像系データ受信側で受信されてもよい。また、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を命令または要求する情報（無効化に関連する情報）が、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）を介して制御系通信ホストから制御系通信デバイスへ送信されてもよい。つまり、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能の無効化を命令または要求する情報（無効化に関連する情報）は、画像系通信が開始（例えば、画像系通信の拡張パケットが送信または受信）される前に、制御系通信向けセッション鍵によって保護された制御系通信を利用して（例えば、他パラメータ情報の一部または全部として）制御系通信ホストから送信または制御系通信デバイスで受信されてもよい。また、画像系通信におけるメッセージ認証またはメッセージ認証を含むセキュリティ機能は、画像系通信の拡張パケット（例えば、拡張パケットヘッダ、Service Descriptor、パケットデータ）を利用して有効化され、制御系通信向けセッション鍵によって保護された制御系通信を利用して無効化されてもよい。この場合にも、画像系通信におけるメッセージ認証の攻撃者による無効化（改竄）を対策できる。
　ところで、画像系通信向けとしてセキュリティ演算部にブロック暗号CBCモードまたはブロック暗号CTRモードの何れかとHMACまたはCMACの何れかとの組み合わせが適用される場合、暗号化鍵とMAC鍵とが必要になる。セッション鍵または新セッション鍵の上述した使用開始タイミング指定は、暗号化鍵向け第１使用開始タイミング指定（例えば、認証付き暗号向け、ブロック暗号CBCモード向け、ブロック暗号CTRモード向け）とMAC鍵向け第２使用開始タイミング指定（例えば、HMAC向け、CMAC向け）とで構成されてもよい。例えば、第１使用開始タイミング指定が第１鍵ID（例えば、認証付き暗号向け、ブロック暗号CBCモード向け、ブロック暗号CTRモード向け）に関連する情報を含み、第２使用開始タイミング指定が第２鍵ID（例えば、HMAC向け、CMAC向け）に関連する情報を含んでもよい。例えば、画像系データ送信側における暗号化鍵（セッション鍵または新セッション鍵）の使用開始に応じて第１使用開始タイミング指定が画像系データ送信側から画像系データ受信側へ送信（つまり、使用開始タイミング指定に応じて暗号化鍵の使用が開始）されるようにしてもよく、画像系データ送信側におけるMAC鍵（セッション鍵または新セッション鍵）の使用開始に応じて第２使用開始タイミング指定が画像系データ送信側から画像系データ受信側へ送信（つまり、使用開始タイミング指定に応じてMAC鍵の使用が開始）されるようにしてもよい。また、画像系データ送信側または画像系データ受信側において、第１使用開始タイミング指定に応じて暗号化鍵（セッション鍵または新セッション鍵）が使用開始されるようにしてもよく、第２使用開始タイミング指定に応じてMAC鍵（セッション鍵または新セッション鍵）が使用開始されるようにしてもよい。ただし、第２使用開始タイミング指定を設けないようにして、画像系データ送信側または画像系データ受信側において、第１使用開始タイミング指定（つまり、使用開始タイミング指定）に応じて暗号化鍵およびMAC鍵（セッション鍵または新セッション鍵）が使用開始されるようにしてもよい。
　ところで、保護された画像系通信（画像系データの送信）が開始される前に画像系通信向けセッション鍵および新セッション鍵が、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）を介して制御系通信ホストから制御系通信デバイスへ送信されてもよい。ただし、保護された画像系通信（画像系データの送信）が開始される前に画像系通信向けセッション鍵および２つ以上の新セッション鍵が制御系通信ホストから制御系通信デバイスへ送信されると、制御系通信ホスト側または制御系通信デバイス側では鍵を保持するための鍵スロット（例えば、メモリ領域）が３つ以上必要になるので、最新の新セッション鍵が制御系通信ホストから送信されるごとに制御系通信ホスト側における２つの鍵スロットに交互に書き込まれること、または最新の新セッション鍵が制御系通信デバイスで受信されるごとに制御系通信デバイス側における２つの鍵スロットに交互に書き込まれることなどによって、制御系通信ホスト側または制御系通信デバイス側で保持される鍵が最大２つとなるようにセッション鍵および新セッション鍵は送信（または受信）および破棄されることが望ましいが、その限りではない。
　ところで、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）を介して、画像系通信向けセッション鍵（新セッション鍵も含む）、アルゴリズム、または他パラメータなどの情報が制御系通信ホストから制御系通信デバイスへ送信されるが、アルゴリズム情報は暗号アルゴリズムの情報を含んでもよく、他パラメータ情報は画像系通信向けセッション鍵または新セッション鍵に対応する鍵ID情報を含んでもよい。鍵ID情報は、例えば、第１セッション鍵（セッション鍵）=0、第２セッション鍵（第１新セッション鍵）=1、第３セッション鍵（第２新セッション鍵）=2、第４セッション鍵（第３新セッション鍵）=3、…であってもよいし、第１セッション鍵（セッション鍵）=1'b0、第２セッション鍵（第１新セッション鍵）=1'b1、第３セッション鍵（第２新セッション鍵）=1'b0、第４セッション鍵（第３新セッション鍵）=1'b1、…であってもよいし、第１セッション鍵（セッション鍵）=1、第２セッション鍵（第１新セッション鍵）=2、第３セッション鍵（第２新セッション鍵）=3、第４セッション鍵（第３新セッション鍵）=4、…であってもよいし、第１セッション鍵（セッション鍵）=1'b1、第２セッション鍵（第１新セッション鍵）=1'b0、第３セッション鍵（第２新セッション鍵）=1'b1、第４セッション鍵（第３新セッション鍵）=1'b0、…であってもよく、鍵ID情報の値はロールオーバーしてもよい。また、鍵ID情報は、例えば、セッション鍵または新セッション鍵が書き込まれる鍵スロットの番号であってもよい。そして、制御系通信デバイスである画像系通信ホストまたは画像系通信デバイスは、拡張パケットヘッダ、パケットデータ、またはService Descriptorなどの何れかを介して画像系データ送信側から画像系データ受信側へ送信された鍵IDに関連する情報（例えば、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDに対応する情報、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDが偶数（Even key）なのか奇数（Odd key）なのかを示す情報）に応じて、画像系通信向けセッション鍵または新セッション鍵を使用開始できる。ただし、拡張パケットヘッダまたはService Descriptorは、拡張パケットが対応するラインごとに膨大な回数が送信される（総データ量が大きい）ので、画像系通信向けセッション鍵または新セッション鍵を送信する場合に用いられる少ない回数の（総データ量が小さい）Vendor defined SPDMメッセージよりも格納できる情報量の制約が厳しい。そのため、拡張パケットヘッダまたはService Descriptorに格納される鍵ID情報の情報量は、Vendor defined SPDMメッセージに格納される鍵ID情報の情報量以下であることが望ましいが、その限りではない。つまり、鍵IDに関連する情報（例えば、鍵ID情報の一部または全部、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDに対応する情報、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDが偶数（Even key）なのか奇数（Odd key）なのかを示す情報）は、画像系通信向けセッション鍵または新セッション鍵の使用が画像系データ送信側で開始される前に、制御系通信向けセッション鍵によって保護された制御系通信を利用して（例えば、他パラメータ情報の一部または全部として）制御系通信ホストから送信または制御系通信デバイスで受信され、画像系通信向けセッション鍵または新セッション鍵の画像系データ送信側における使用開始に応じて（または使用が画像系データ送信側で開始された後に）、画像系通信の拡張パケット内に格納されて画像系データ受信側で受信または画像系データ送信側から送信されてもよい。また、鍵IDに関連する情報（例えば、鍵ID情報の一部または全部）は、画像系通信向けセッション鍵または新セッション鍵の使用が画像系データ送信側で開始される前に、制御系通信向けセッション鍵によって保護された制御系通信を利用して（例えば、他パラメータ情報の一部または全部として）制御系通信ホストから送信または制御系通信デバイスで受信され、鍵IDに関連する情報の情報量を圧縮した情報（例えば、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDに対応する情報、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDが偶数（Even key）なのか奇数（Odd key）なのかを示す情報）は、画像系通信向けセッション鍵または新セッション鍵の画像系データ送信側における使用開始に応じて（または使用が画像系データ送信側で開始された後に）、画像系通信の拡張パケット内に格納されて画像系データ受信側で受信または画像系データ送信側から送信されてもよい。また、制御系通信向けセッション鍵によって保護された制御系通信（例えば、VENDOR_DEFINED_REQUEST要求メッセージ）を利用して、最新の画像系通信向け新セッション鍵とこれに対応する鍵IDに関連する情報（例えば、鍵ID情報の一部または全部）とが制御系通信ホストから送信されて制御系通信デバイスで受信された場合、その応答として、制御系通信デバイスが保持している２つの画像系通信向けセッション鍵または新セッション鍵に対応する２つの鍵IDに関連する情報（例えば、鍵ID情報の一部または全部）を、制御系通信（例えば、VENDOR_DEFINED_RESPONSE応答メッセージ）を利用して制御系通信デバイスから制御系通信ホストへ送信してもよい。また、制御系通信向けセッション鍵によって保護された制御系通信（例えば、VENDOR_DEFINED_REQUEST要求メッセージ）を利用して、最新の画像系通信向け新セッション鍵とこれに対応する鍵IDに関連する情報（例えば、鍵ID情報の一部または全部）とが制御系通信ホストから送信されて制御系通信デバイスで受信された場合、その応答として、２つの鍵IDに関する不具合の有無（例えば、２つの鍵IDが不連続か否か、２つの鍵IDが両方とも偶数か否か、２つの鍵IDが両方とも奇数か否か、想定外の鍵スロット番号か否か）を示す情報が、制御系通信（例えば、VENDOR_DEFINED_RESPONSE応答メッセージ）を利用して制御系通信デバイスから制御系通信ホストへ送信されてもよい。これらの場合、制御系通信デバイスが保持している画像系通信向け鍵IDに関連する情報の情報量を圧縮した情報（例えば、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDに対応する情報、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDが偶数（Even key）なのか奇数（Odd key）なのかを示す情報）に間違いがないことを、制御系通信ホストが事前確認できるので、制御系通信デバイスである画像系通信ホストまたは画像系通信デバイスによる誤った暗号化（復号）またはメッセージ認証を回避できる。例えば、制御系通信（例えば、VENDOR_DEFINED_RESPONSE応答メッセージ）を利用して制御系通信デバイスから送信されて制御系通信ホストで受信された情報に基づき、制御系通信デバイスが保持している２つの画像系通信向けセッション鍵または新セッション鍵に不具合があると制御系通信ホストが判断する場合、制御系通信ホストはさらに新たな新セッション鍵（最新セッション鍵）を導出または生成し、最新セッション鍵と最新セッション鍵に対応する鍵IDに関連する情報とを、制御系通信向けセッション鍵によって保護された制御系通信（例えば、VENDOR_DEFINED_REQUEST要求メッセージ）を利用して制御系通信ホストから制御系通信デバイスへ送信してもよい。また、例えば、制御系通信（例えば、VENDOR_DEFINED_RESPONSE応答メッセージ）を利用して制御系通信デバイスから送信されて制御系通信ホストで受信された情報に基づき、制御系通信デバイスが保持している２つの画像系通信向け新セッション鍵に不具合がないと制御系通信ホストが判断する場合、最新の画像系通信向け新セッション鍵を使用開始してよいことを示す情報を、制御系通信向けセッション鍵によって保護された制御系通信（例えば、VENDOR_DEFINED_REQUEST要求メッセージ）を利用して制御系通信ホストから制御系通信デバイス（特に、画像系データ送信側）へ送信してもよい。ただし、例えば、ePH2[27:25]=Service Descriptor[3:1]=0b001：メッセージ認証あり・暗号化あり・Key1（Even key）、ePH2[27:25]=Service Descriptor[3:1]=0b010：メッセージ認証あり・暗号化なし・Key2（Even key）、ePH2[27:25]=Service Descriptor[3:1]=0b100：メッセージ認証あり・暗号化あり・Key3（Odd key）、ePH2[27:25]=Service Descriptor[3:1]=0b101：メッセージ認証あり・暗号化なし・Key4（Odd key）、と定義してもよい。また、例えば、ePH2[27:25]=Service Descriptor[3:1]=0b001：メッセージ認証あり・暗号化あり・Key1（Odd key）、ePH2[27:25]=Service Descriptor[3:1]=0b010：メッセージ認証あり・暗号化なし・Key2（Odd key）、ePH2[27:25]=Service Descriptor[3:1]=0b100：メッセージ認証あり・暗号化あり・Key3（Even key）、ePH2[27:25]=Service Descriptor[3:1]=0b101：メッセージ認証あり・暗号化なし・Key4（Even key）、と定義してもよい。これらの場合は暗号化の有効化と無効化との切り替え（ON/OFF）によってセッション鍵を変える必要があるので、例えば、ePH2[27:25]=Service Descriptor[3:1]=0b011：メッセージ認証あり・暗号化なし・Key1、ePH2[27:25]=Service Descriptor[3:1]=0b110：メッセージ認証あり・暗号化なし・Key3、と定義することによって、同じセッション鍵で暗号化の有効化と無効化とを切り替え（ON/OFF）してもよい。具体的には、「0b001/0b011」の切り替えまたは「0b100/0b110」の切り替えによって、同じセッション鍵で暗号化の「有効化/無効化（ON/OFF）」を切り替え可能だが、これらのビット割り当てや表現は異なってもよい。例えば、ePH2[27:25]=Service Descriptor[3:1]=0b010：メッセージ認証あり・暗号化なし・Key1、ePH2[27:25]=Service Descriptor[3:1]=0b101：メッセージ認証あり・暗号化なし・Key3、としてもよいし、Key1またはKey3をKey0と置き換えてもよいし、Key2またはKey4をKey1と置き換えてもよい。同様に、例えば、ePH2[27:25]=Service Descriptor[3:1]=0b011：メッセージ認証あり・暗号化あり・Key2、ePH2[27:25]=Service Descriptor[3:1]=0b110：メッセージ認証あり・暗号化あり・Key4、と定義することによって、同じセッション鍵で暗号化の有効化と無効化とを切り替え（ON/OFF）してもよい。具体的には、「0b011/0b010」の切り替えまたは「0b110/0b101」の切り替えによって、同じセッション鍵で暗号化の「有効化/無効化（ON/OFF）」を切り替え可能だが、これらのビット割り当てや表現は異なってもよい。また、Key1とKey2とが同一か否かを示す情報（例えば、1'b1：Key1とKey2とは異なる、1'b0：Key1とKey2とは同一）またはKey3とKey4とが同一か否かを示す情報（例えば、1'b1：Key3とKey4とは異なる、1'b0：Key3とKey4とは同一）が、制御系通信ホストと制御系通信デバイスとの間の保護されたセッション（例えば、SPDMセッション）を介して制御系通信ホストから制御系通信デバイスへ送信されることによって、同じセッション鍵で暗号化の有効化と無効化とを切り替え（ON/OFF）してもよい。ただし、これらのビット割り当て（1'b1/1'b0）は、逆に割り当てられてもよいし、1ビットの領域ではなく2ビット以上の領域に割り当てられてもよい。つまり、Key1とKey2とが同一か否かを示す情報またはKey3とKey4とが同一か否かを示す情報は、画像系通信が開始（例えば、画像系通信の拡張パケットが送信または受信）される前に、制御系通信向けセッション鍵によって保護された制御系通信を利用して（例えば、他パラメータ情報の一部または全部として）制御系通信ホストから送信または制御系通信デバイスで受信され、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDに対応する情報（例えば、Key1、Key2、Key3、またはKey4の何れかの指定）は、画像系通信の拡張パケッ
ト（例えば、拡張パケットヘッダ、Service Descriptor、パケットデータ）内に格納されて画像系データ受信側で受信または画像系データ送信側から送信されてもよい。また、Key1とKey2とが同一か否かを示す情報またはKey3とKey4とが同一か否かを示す情報は、画像系通信向けセッション鍵または新セッション鍵の使用が画像系データ送信側で開始される前に、制御系通信向けセッション鍵によって保護された制御系通信を利用して（例えば、他パラメータ情報の一部または全部として）制御系通信ホストから送信または制御系通信デバイスで受信され、画像系通信向けセッション鍵または新セッション鍵のうち使用開始する鍵または使用開始した鍵の鍵IDに対応する情報（例えば、Key1、Key2、Key3、またはKey4の何れかの指定）は、画像系通信向けセッション鍵または新セッション鍵の画像系データ送信側における使用開始に応じて（または使用が画像系データ送信側で開始された後に）、画像系通信の拡張パケット（例えば、拡張パケットヘッダ、Service Descriptor、パケットデータ）内に格納されて画像系データ受信側で受信または画像系データ送信側から送信されてもよい。また、Key1とKey2とが同一か否かを示す情報またはKey3とKey4とが同一か否かを示す情報の送信または受信は、画像系通信ホストと画像系通信デバイスとの間の事前合意（Private contract）で代用されてもよい。つまり、画像系通信ホストと画像系通信デバイスとは、ぞれぞれ、事前合意された情報に従ってKey1とKey2とが同一か否かまたはKey3とKey4とが同一か否かを判断してもよく、事前合意された情報に従って同じセッション鍵で暗号化の有効化と無効化とを切り替え（ON/OFF）してもよい。具体的には、Key1とKey2とが同一またはKey3とKey4とが同一であることが事前合意された場合、「0b001/0b010」の切り替えまたは「0b100/0b101」の切り替えによって、同じセッション鍵で暗号化の「有効化/無効化（ON/OFF）」を切り替え可能だが、これらのビット割り当てや表現は異なってもよい。
　＜セッション鍵の状態の把握＞
　図２０８に示されている通信システム３１００は、アプリケーションプロセッサ３１１０およびイメージセンサ３１２０を備える。アプリケーションプロセッサ３１１０とイメージセンサ３１２０とは、例えば、１本の通信経路３１３０で接続される。通信経路３１３０は、制御系通信経路かつ画像系通信経路（例えば、A-PHY、USLに準拠するD-PHYまたはC-PHYなど）である。なお、アプリケーションプロセッサ３１１０とイメージセンサ３１２０とが、複数本の通信経路３１３０で接続されてもよい。また、アプリケーションプロセッサ３１１０とイメージセンサ３１２０とが、制御系通信経路と画像系通信経路とが別々に構成された複数本の通信経路で接続されてもよい。
　アプリケーションプロセッサ３１１０は、通信制御部３１１０ａと、ブリッジ（Bridge）一端３１１０ｂとを備える。通信制御部３１１０ａは、SSMC（Secure Session Manager Controller）またはアプリケーションプロセッサ（SoCまたはSystem on Chipとも称する）である。通信制御部３１１０ａは、例えば、SPDMリクエスタ３１１１（例えばCCIマスタ）、Control Planeホスト３１１２（例えばCCIマスタ）およびData Planeホスト３１１３（画像データ受信部）を含む。
　イメージセンサ３１２０は、通信制御機能を有するセンサ部３１２０ａと、ブリッジ他端３１２０ｂとを備える。センサ部３１２０ａは、例えば、撮像部、SPDMレスポンダ３１２１（例えばCCIスレーブ）、Control Planeデバイス３１２２（例えばCCIスレーブ）およびData Planeデバイス３１２３（画像データ送信部）を含む。ブリッジ一端３１１０ｂおよびブリッジ他端３１２０ｂは省略されてもよい。
　例えば、通信経路３１３０において、SPDMリクエスタ３１１１とSPDMレスポンダ３１２１との間にSPDMセッションが確立される。また、例えば、通信経路３１３０において、Control Planeホスト３１１２とControl Planeデバイス３１２２との間にControl Planeセッションが確立される。また、例えば、通信経路３１３０において、Data Planeホスト３１１３とData Planeデバイス３１２３との間にData Planeセッションが確立される。
　Control Planeセッションは、Control Planeセッション鍵を用いて確立される。Control通信制御部３１１０ａがControl Planeセッション鍵を生成し、SPDMセッションを介してセンサ部３１２０ａに送信する。センサ部３１２０ａは、SPDMセッションを介してControl Planeセッション鍵を受信する。このようにして、通信制御部３１１０ａからセンサ部３１２０ａに渡されたControl Planeセッション鍵を用いて、Control Planeセッションが確立される。
　Data Planeセッションは、Data Planeセッション鍵を用いて確立される。通信制御部３１１０ａがData Planeセッション鍵を生成し、SPDMセッションを介してセンサ部３１２０ａに送信する。センサ部３１２０ａは、SPDMセッションを介してData Planeセッション鍵を受信する。このようにして、通信制御部３１１０ａからセンサ部３１２０ａに渡されたData Planeセッション鍵を用いて、Data Planeセッションが確立される。
　SPDMリクエスタ３１１１とSPDMレスポンダ３１２１との間では、SPDMに準拠する要求メッセージがSPDMリクエスタ３１１１からSPDMレスポンダ３１２１に送信され、SPDMに準拠する応答メッセージがSPDMレスポンダ３１２１からSPDMリクエスタ３１１１に送信される。
　Control Planeホスト３１１２とControl Planeデバイス３１２２との間では、Control Planeセッション鍵によって保護されたWrite Command（CCI Write）もしくはRead Command（CCI Read）がControl Planeホスト３１１２からControl Planeデバイス３１２２に送信される。また、Control Planeホスト３１１２とControl Planeデバイス３１２２との間では、Control Planeセッション鍵によって保護されたRead Response（CCI Read戻り値）がControl Planeデバイス３１２２からControl Planeホスト３１１２に送信される。
　Data Planeホスト３１１３とData Planeデバイス３１２３との間では、Data Planeセッション鍵によって保護されたフレームスタート，埋め込みデータ，画像データ，ユーザ定義データもしくはフレームエンドがData Planeデバイス３１２３からData Planeホスト３１１３に送信される。
　このようなデータ送受信が行われることにより、センサ部３１２０ａが送信する情報（例えば、新セッション鍵の使用開始タイミング指定）に基づき、通信制御部３１１０ａがセッション鍵の更新要否を判断し、最新のセッション鍵を生成して、センサ部３１２０ａに送信することができる。なお、イメージセンサ３１２０の代わりにディスプレイが設けられ、センサ部３１２０ａの代わりにディスプレイパネルが設けられてもよい。この場合、Data Planeホスト３１１３とData Planeデバイス３１２３との間では、Data Planeセッション鍵によって保護されたフレームスタート，埋め込みデータ，画像データ，ユーザ定義データもしくはフレームエンドがData Planeホスト３１１３からData Planeデバイス３１２３に送信される。なお、HostまたはDeviceは、Agentを含む表現で称されてもよい。また、Control planeは、ESS CCI（Enhanced Safety and Security Camera Control Interface）の一部または全部を含む表現またはACMP（A-PHY Control & Management Protocol）の一部または全部を含む表現で称されてもよい。また、Data planeはSEP（Service Extension Packet）の一部または全部を含む表現で称されてもよい。Control planeまたはData planeは、画像関連の用途だけではなく、Power Management、IoT（Internet of Things）、GNSS（Global Navigation Satellite System）、GPS（Global Positioning SystemまたはGlobal Positioning Satellite）などの非画像関連の用途に適用されてもよい。
　次に、通信システム３１００の変形例について説明する。
[変形例Ａ]
　図２０９は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、アプリケーションプロセッサ３１１０とイメージセンサ３１２０とが、１本の制御系通信経路３１３１および１本の画像系通信経路３１３２で接続される。制御系通信経路３１３１は、例えば、CCIである。画像系通信経路３１３２は、例えば、C-PHYまたはD-PHYである。なお、本変形例において、アプリケーションプロセッサ３１１０とイメージセンサ３１２０とが、複数本の制御系通信経路３１３１および複数本の画像系通信経路３１３２で接続でれてもよい。また、アプリケーションプロセッサ３１１０とイメージセンサ３１２０とが、１本の通信経路３１３０で接続されてもよい。
　本変形例では、通信制御部３１１０ａがSPDMリクエスタ３１１１ａおよびControl Planeホスト３１１２を含み、ブリッジ一端３１１０ｂがData Planeホスト３１１３およびSPDMレスポンダ３１１４を含む。本変形例では、センサ部３１２０ａがSPDMレスポンダ３１２１ａおよびControl Planeデバイス３１２２を含み、ブリッジ他端３１２０ｂがSPDMレスポンダ３１２４およびData Planeデバイス３１２３を含む。
　例えば、通信経路３１３１において、SPDMリクエスタ３１１１ａとSPDMレスポンダ３１２１ａ，３１２４，３１１４との間にSPDMセッションが確立される。また、例えば、通信経路３１３１において、Control Planeホスト３１１２とControl Planeデバイス３１２２との間にControl Planeセッションが確立される。また、例えば、通信経路３１３２において、Data Planeホスト３１１３とData Planeデバイス３１２３との間にData Planeセッションが確立される。
　Control Planeセッションは、Control Planeセッション鍵を用いて確立される。Control通信制御部３１１０ａがControl Planeセッション鍵を生成し、SPDMセッションを介してセンサ部３１２０ａに送信する。センサ部３１２０ａは、SPDMセッションを介してControl Planeセッション鍵を受信する。このようにして、通信制御部３１１０ａからセンサ部３１２０ａに渡されたControl Planeセッション鍵を用いて、Control Planeセッションが確立される。
　Data Planeセッションは、Data Planeセッション鍵を用いて確立される。通信制御部３１１０ａがData Planeセッション鍵を生成し、SPDMセッションを介してセンサ部３１２０ａに送信する。センサ部３１２０ａは、SPDMセッションを介してData Planeセッション鍵を受信する。このようにして、通信制御部３１１０ａからセンサ部３１２０ａに渡されたData Planeセッション鍵を用いて、Data Planeセッションが確立される。Data Planeセッション鍵と、Control Planeセッション鍵とは、互いに異なっていることが望ましい。
　SPDMリクエスタ３１１１ａとSPDMレスポンダ３１２１ａ，３１２４，３１１４との間では、SPDMに準拠する要求メッセージがSPDMリクエスタ３１１１ａからSPDMレスポンダ３１２１ａ，３１２４，３１１４に送信され、SPDMに準拠する応答メッセージがSPDMレスポンダ３１２１ａ，３１２４，３１１４からSPDMリクエスタ３１１１ａに送信される。
　Control Planeホスト３１１２とControl Planeデバイス３１２２との間では、Control Planeセッション鍵によって保護されたWrite Command（CCI Write）もしくはRead Command（CCI Read）がControl Planeホスト３１１２からControl Planeデバイス３１２２に送信される。また、Control Planeホスト３１１２とControl Planeデバイス３１２２との間では、Control Planeセッション鍵によって保護されたRead Response（CCI Read戻り値）がControl Planeデバイス３１２２からControl Planeホスト３１１２に送信される。
　Data Planeホスト３１１３とData Planeデバイス３１２３との間では、Data Planeセッション鍵によって保護されたフレームスタート，埋め込みデータ，画像データ，ユーザ定義データもしくはフレームエンドがData Planeデバイス３１２３からData Planeホスト３１１３に送信される。
　本変形例では、通信制御部３１１０ａとセンサ部３１２０ａとの間の制御系通信は、Control Planeセッション鍵によって保護され、ブリッジ一端３１１０ｂとブリッジ他端３１２０ｂとの間の画像系通信は、Data Planeセッション鍵によって保護される。しかし、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の画像系通信や、ブリッジ他端３１２０ｂとセンサ部３１２０ａとの間の画像系通信は、Data Planeセッション鍵によって保護されない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がブリッジ他端３１２０ｂからブリッジ一端３１１０ｂに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、ブリッジ一端３１１０ｂおよびブリッジ他端３１２０ｂが、最新のセッション鍵を適切なタイミングで受信できない。
[変形例Ｂ]
　図２１０は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、変形例Ａに係る通信システム３１００において、Control Planeホスト３１１２がブリッジ一端３１１０ｂに設けられる。この場合、ブリッジ一端３１１０ｂとセンサ部３１２０ａとの間の制御系通信は、Control Planeセッション鍵によって保護される。しかし、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の制御系通信は、Control Planeセッション鍵によって保護されない。さらに、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の画像系通信や、ブリッジ他端３１２０ｂとセンサ部３１２０ａとの間の画像系通信は、Data Planeセッション鍵によって保護されない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がブリッジ他端３１２０ｂからブリッジ一端３１１０ｂに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、ブリッジ一端３１１０ｂおよびブリッジ他端３１２０ｂが、最新のセッション鍵を適切なタイミングで受信できない。
[変形例Ｃ]
　図２１１は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、変形例Ａに係る通信システム３１００において、Data Planeデバイス３１２３がセンサ部３１２０ａに設けられ、ブリッジ他端３１２０ｂのSPDMレスポンダ３１２４が省略される。ブリッジ他端３１２０ｂは省略されてもよい。この場合、通信制御部３１１０ａとセンサ部３１２０ａとの間の制御系通信は、Control Planeセッション鍵によって保護される。また、ブリッジ一端３１１０ｂとセンサ部３１２０ａとの間の画像系通信は、Data Planeセッション鍵によって保護される。しかし、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の画像系通信は、Data Planeセッション鍵によって保護されない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がセンサ部３１２０ａからブリッジ一端３１１０ｂに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、ブリッジ一端３１１０ｂおよびセンサ部３１２０ａが、最新のセッション鍵を適切なタイミングで受信できない。
[変形例Ｄ]
　図２１２は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、変形例Ｃに係る通信システム３１００において、Control Planeホスト３１１２がブリッジ一端３１１０ｂに設けられる。ブリッジ他端３１２０ｂは省略されてもよい。この場合、ブリッジ一端３１１０ｂとセンサ部３１２０ａとの間の制御系通信は、Control Planeセッション鍵によって保護され、ブリッジ一端３１１０ｂとセンサ部３１２０ａとの間の画像系通信は、Data Planeセッション鍵によって保護される。しかし、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の制御系通信は、Control Planeセッション鍵によって保護されない。また、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の画像系通信は、Data Planeセッション鍵によって保護されない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がセンサ部３１２０ａからブリッジ一端３１１０ｂに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、ブリッジ一端３１１０ｂおよびセンサ部３１２０ａが、最新のセッション鍵を適切なタイミングで受信できない。
[変形例Ｅ]
　図２１３は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、変形例Ａに係る通信システム３１００において、Control Planeデバイス３１２２がブリッジ他端３１２０ｂに設けられ、センサ部３１２０ａのSPDMレスポンダ３１２１ａが省略される。この場合、通信制御部３１１０ａとブリッジ他端３１２０ｂとの間の制御系通信は、Control Planeセッション鍵によって保護され、ブリッジ一端３１１０ｂとブリッジ他端３１２０ｂとの間の画像系通信は、Data Planeセッション鍵によって保護される。しかし、ブリッジ他端３１２０ｂとセンサ部３１２０ａとの間の制御系通信は、Control Planeセッション鍵によって保護されない。また、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の画像系通信や、ブリッジ他端３１２０ｂとセンサ部３１２０ａとの間の画像系通信は、Data Planeセッション鍵によって保護されない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がブリッジ他端３１２０ｂからブリッジ一端３１１０ｂに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、ブリッジ一端３１１０ｂおよびブリッジ他端３１２０ｂが、最新のセッション鍵を適切なタイミングで受信できない。
[変形例Ｆ]
　図２１４は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、変形例Ｅに係る通信システム３１００において、Control Planeホスト３１１２がブリッジ一端３１１０ｂに設けられる。この場合、ブリッジ一端３１１０ｂとブリッジ他端３１２０ｂとの間の制御系通信は、Control Planeセッション鍵によって保護され、ブリッジ一端３１１０ｂとブリッジ他端３１２０ｂとの間の画像系通信は、Data Planeセッション鍵によって保護される。しかし、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の制御系通信や、ブリッジ他端３１２０ｂとセンサ部３１２０ａとの間の制御系通信は、Control Planeセッション鍵によって保護されない。また、通信制御部３１１０ａとブリッジ一端３１１０ｂとの間の画像系通信や、ブリッジ他端３１２０ｂとセンサ部３１２０ａとの間の画像系通信は、Data Planeセッション鍵によって保護されない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がブリッジ他端３１２０ｂからブリッジ一端３１１０ｂに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、ブリッジ一端３１１０ｂおよびブリッジ他端３１２０ｂが、最新のセッション鍵を適切なタイミングで受信できない。
[変形例Ｇ]
　図２１５は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、変形例Ｄに係る通信システム３１００において、アプリケーションプロセッサ３１１０が通信制御部３１１０ｃを更に備える。本変形例では、SPDMリクエスタ３１１１ａが通信制御部３１１０ａに設けられ、SPDMレスポンダ３１１４、Control Planeホスト３１１２およびData Planeホスト３１１３が通信制御部３１１０ｃに設けられる。本変形例において、通信制御部３１１０ａは、SSMCまたはアプリケーションプロセッサ（Root SoC）であり、通信制御部３１１０ｃは、アプリケーションプロセッサ（SoC）である。ブリッジ一端３１１０ｂおよびブリッジ他端３１２０ｂは省略されてもよい。
　本変形例では、通信制御部３１１０ａと通信制御部３１１０ｃとの間の制御系通信は、例えば、CCI(I2CまたはI3C)、またはA-PHYであってもよいし、EthernetまたはUSB(Universal Serial Bus)であってもよい。
　Control Planeセッションは、Control Planeセッション鍵を用いて確立される。Control通信制御部３１１０ａがControl Planeセッション鍵を生成し、SPDMセッションを介して通信制御部３１１０ｃおよびセンサ部３１２０ａに送信する。通信制御部３１１０ｃおよびセンサ部３１２０ａは、SPDMセッションを介してControl Planeセッション鍵を受信する。このようにして、通信制御部３１１０ａから通信制御部３１１０ｃおよびセンサ部３１２０ａのそれぞれに渡された同一のControl Planeセッション鍵を用いて、Control Planeセッションが確立される。
　Data Planeセッションは、Data Planeセッション鍵を用いて確立される。通信制御部３１１０ａがData Planeセッション鍵を生成し、SPDMセッションを介して通信制御部３１１０ｃおよびセンサ部３１２０ａに送信する。通信制御部３１１０ｃおよびセンサ部３１２０ａは、SPDMセッションを介してData Planeセッション鍵を受信する。このようにして、通信制御部３１１０ａから通信制御部３１１０ｃおよびセンサ部３１２０ａのそれぞれに渡された同一のData Planeセッション鍵を用いて、Data Planeセッションが確立される。
　この場合、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がセンサ部３１２０ａから通信制御部３１１０ｃに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、通信制御部３１１０ｃおよびセンサ部３１２０ａが、最新のセッション鍵を適切なタイミングで受信できない。
[変形例Ｈ]
　図２１６は、通信システム３１００のブロックの一変形例を示す図である。本変形例では、変形例Ｇに係る通信システム３１００において、Data Planeホスト３１１３がブリッジ一端３１１０ｂに設けられ、SPDMレスポンダ３１１５が更にブリッジ一端３１１０ｂに設けられる。ブリッジ他端３１２０ｂは省略されてもよい。
　Data Planeセッションは、Data Planeセッション鍵を用いて確立される。通信制御部３１１０ａがData Planeセッション鍵を生成し、SPDMセッションを介してブリッジ一端３１１０ｂおよびセンサ部３１２０ａに送信する。ブリッジ一端３１１０ｂおよびセンサ部３１２０ａは、SPDMセッションを介してData Planeセッション鍵を受信する。このようにして、通信制御部３１１０ａからブリッジ一端３１１０ｂおよびセンサ部３１２０ａのそれぞれに渡された同一のData Planeセッション鍵を用いて、Data Planeセッションが確立される。
　この場合、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。そのため、例えば、Data Plane新セッション鍵の使用開始タイミング指定がセンサ部３１２０ａからブリッジ一端３１１０ｂに自主送信されたとしても、通信制御部３１１０ａはData Planeセッション鍵の更新要否を判断できない。その結果、通信制御部３１１０ａが最新のセッション鍵を適切なタイミングで生成し、送信することができない。つまり、ブリッジ一端３１１０ｂおよびセンサ部３１２０ａが、最新のセッション鍵を適切なタイミングで受信できない。
＜リプレイ攻撃対策＞
　ところで、Control Plane向けに２つ以上のMACモードが設けられていてもよい。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、MAC値を、次フレームの高速データ送信の埋め込みデータ、または、次CCIコマンドのデータに格納して、通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂに送信または通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂから受信してもよい。このときのMAC値は、通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂとセンサ部３１２０ａまたはブリッジ他端３１２０ｂとの間で所定期間内または所定ビット幅内に送信された書き込み命令、読み出し命令および読み出し応答（つまり、CCIコマンド）の一部もしくは全部をメッセージ認証の保護対象とする。このときのMACモードをRunningモードと称する。
　一方、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、MAC値を、書き込み命令の一部、または、読み出し命令および読み出し応答の一部として、通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂに送信または通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂから受信してもよい。このときのMAC値は、通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂとセンサ部３１２０ａまたはブリッジ他端３１２０ｂとの間で所定期間内または所定ビット幅内に送信された書き込み命令、読み出し命令および読み出し応答の一部もしくは全部をメッセージ認証の保護対象とする。このときのMACモードをIndividualモードと称する。
　RunningモードとIndividualモードとは、同時に使用されてもよいし、時分割的に切り替えて使用されてもよい。このときのMACモードをDualモード(Running/Individual)と称する。また、読み出し命令および読み出し応答の一部もしくは全部をメッセージ認証の保護対象とするMACモードをReadモードと称する。また、書き込み命令の一部もしくは全部をメッセージ認証の保護対象とするMACモードをWriteモードと称する。また、読み出し命令および読み出し応答と、書き込み命令との一連の組み合わせの一部もしくは全部をメッセージ認証の保護対象とするMACモードをDualモード(Read/Write)と称する。
　ところで、GMACまたはGCMでは、Individualモードにおいて、充分に長い時間、ユニークな初期化ベクトルIVが用いられる（図２１７）。そのため、この初期化ベクトルIVは、リプレイ攻撃対策として用いられ得る。従来、Control Plane初期化ベクトルIVは、例えば、図２１８（Ａ）に示したように、３２ビットのControl Planeソルト（乱数）、５６ビットのControl Plane追加メッセージカウンタおよび８ビットのControl Planeメッセージカウンタを含む。
　上述の通信システム３１００において、Control Plane初期化ベクトルIVは、例えば、図２１８（Ｂ）に示したように、３２ビットのControl Planeソルト（乱数）、５２ビットのControl Plane追加メッセージカウンタ、８ビットのControl Planeメッセージカウンタ、２ビットのControl PlaneのMACモードを示す情報、および２ビットのControl PlaneのRead/Writeモードを示す情報を含んでいてもよい。Control PlaneのMACモードを示す情報には、例えば、Runningモード、IndividualモードもしくはDualモード(Running/Individual)を示す情報が含まれる。また、Control PlaneのRead/Writeモードを示す情報には、例えば、Readモード、WriteモードもしくはDualモード(Read/Write) を示す情報が含まれる。これらのビット幅（例えば、３２ビット、５６ビット、５２ビット）は例示であり、異なるビット幅で構成されてもよい。
　このように、Control Plane初期化ベクトルIVが図２１８（Ｂ）に示した情報を含む場合、MACモードまたはRead/Writeモードに関わらず、同じセッション鍵または同じメッセージカウンタを用いることが可能になる。通信制御部３１１０ａは、Control Plane初期化ベクトルIVに用いられるソルトを生成または導出し、VENDOR_DEFINED_REQUEST要求メッセージ（Control Planeソルト設定要求）によって、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａに送信してもよい。通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、Control Planeソルト設定要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージ（例えば、ACK,NACK,同じソルト格納）またはERROR応答メッセージによって、Control Planeソルト設定応答を通信制御部３１１０ａに送信してもよい。
　同様に、通信制御部３１１０ａは、Data Plane初期化ベクトルIVに用いられるソルトを生成または導出し、VENDOR_DEFINED_REQUEST要求メッセージ（Data Planeソルト設定要求）によって、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａに送信してもよい。通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、Data Planeソルト設定要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージ（例えば、ACK,NACK,同じソルト格納）またはERROR応答メッセージによって、Data Planeソルト設定応答を通信制御部３１１０ａに送信してもよい。
　通信制御部３１１０ａ、通信制御部３１１０ｃ、またはブリッジ一端３１１０ｂとブリッジ他端３１２０ｂまたはセンサ部３１２０ａは、例えば、同じセッション鍵で同じ初期化ベクトル値IVを用いてメッセージのGMAC値などのMAC値を演算して、メッセージおよびMAC値を送信するとする。このとき、通信制御部３１１０ａ、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、例えば、図２１９に示したように、メッセージカウント値(MC値)が一周する期間を超えて、MAC値として、初期化ベクトル値IVを１ずつインクリメントまたはデクリメントした値を用いてもよい。このようにすることで、リプレイ攻撃を不可能にすることが可能となる。
　ただし、メッセージ認証コード（MAC）として、CMACまたはHMACが用いられる場合には、例えば、図２２０に示したように、メッセージカウンタがリプレイ攻撃対策にならないことがある。そこで、CMACまたはHMACでは、Individualモードにおいて、メッセージカウンタのバイト幅もしくはビット幅を拡張（可変）できるようにしてもよい（図２２１）。
　通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージ、CCI拡張ヘッダ（EXTENDED HEADER）またはControl planeホストとControl planeデバイスとの間の事前合意（Private contract）によって、通信制御部３１１０ｃ、センサ部３１２０ａまたはブリッジにおけるCCIメッセージカウンタのバイト幅もしくはビット幅を設定してもよい。VENDOR_DEFINED_REQUEST要求メッセージ（Control planeメッセージカウンタ設定要求）が、例えば、図２２２に示したようなフォーマット構成となっていてもよい。
　なお、CCI拡張ヘッダが、図２２２に示したようなフォーマット構成と同様の構成となっていてもよい。CCI拡張ヘッダは、例えば、機能安全の要否（ON/OFF）、セキュリティ機能の要否（ON/OFF）、暗号化の要否（ON/OFF）、メッセージカウンタ（MC）の要否（ON/OFF）、メッセージ認証コード（MAC）の要否（ON/OFF）またはCRCの要否（ON/OFF）を含む。
　図２２３は、書き込み命令の一例を示したものである。通信制御部３１１０ｃ、センサ部３１２０ａまたはブリッジは、Control planeメッセージカウンタ設定要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージ（例えば、ACK,NACK,同じメッセージカウンタ設定値格納）またはERROR応答メッセージによって、Control planeメッセージカウンタ設定応答を通信制御部３１１０ａに送信してもよい。このとき、通信制御部３１１０ｃ、センサ部３１２０ａまたはブリッジは、メッセージカウンタを、例えば、初期値が０または１で、所定条件を満たすSTOP Conditionが送信されるごとにインクリメントまたはデクリメントする。
　ところで、拡張パケットヘッダやCCI拡張ヘッダのメッセージ認証、またはメッセージ認証を含むセキュリティ機能のON/OFFは、改竄されるリスクがある。そのため、例えば、図２２４に示したように、Vendor Defined SPDMメッセージによってMACタグ長を設定することが望ましい。また、メッセージ認証、またはメッセージ認証を含むセキュリティ機能の無効化を許容するか否かを示す情報をVendor Defined SPDMメッセージで設定することが望ましい。上記の無効化を許容するか否かは、Control planeホストとControl planeデバイスとの間の事前合意で代用されてもよい。画像系通信または制御系通信におけるMAC無効化に関連する情報（メッセージ認証、またはメッセージ認証を含むセキュリティ機能の無効化を許容するか否かを示す情報）は、後述するメッセージ認証ポリシーとしてもよいし、後述する機能レジスタで定義されてもよい。
　図２２５は、読み出し命令および読み出し応答の一例を示したものである。通信制御部３１１０ａは、VENDOR_DEFINED_RESPONSE要求メッセージ、CCI拡張ヘッダ（EXTENDED HEADER）またはControl planeホストとControl planeデバイスとの間の事前合意（Private contract）によって、通信制御部３１１０ｃ、センサ部３１２０ａまたはブリッジにおけるCCIメッセージ認証コードのバイト幅もしくはビット幅を設定してもよい。CCI拡張ヘッダが、例えば、図２２４に示したようなフォーマット構成となっていてもよい。
　通信制御部３１１０ｃ、センサ部３１２０ａまたはブリッジは、Control planeメッセージ認証コード設定要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージ（例えば、ACK,NACK,同じMAC設定値格納）またはERROR応答メッセージによって、Control planeメッセージ認証コード設定応答を通信制御部３１１０ａに送信してもよい。同様に、通信制御部３１１０ａは、画像系通信MACのバイト幅もしくはビット幅を可変できるフォーマット構成にし、VENDOR_DEFINED_REQUEST要求メッセージ、拡張パケットヘッダまたはData planeホストとData planeデバイスとの間の事前合意（Private contract）によって、通信制御部３１１０ｃ、センサ部３１２０ａまたはブリッジにおける画像系通信MACのバイト幅もしくはビット幅を設定してもよい。
　図２２４において、VENDOR_DEFINED_REQUEST要求メッセージの例のCCIを別表現（例えば、CSI2,DSI2）に変えれば、Data planeメッセージ認証コード設定要求となる。通信制御部３１１０ｃ、センサ部３１２０ａまたはブリッジは、Data planeメッセージ認証コード設定要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージ（例えば、ACK,NACK,同じMAC設定値格納）またはERROR応答メッセージによって、Control planeメッセージ認証コード設定応答を通信制御部３１１０ａに送信してもよい。
　なお、図２２３、図２２５におけるコマンド例の改行は図面都合であり、各行のコマンド列は連続的または断続的に送信されてもよい。図２２３、図２２５におけるコマンド例の第１行目の末尾は、A（Acknowledge）ではなく、P（STOP condition）であってもよい。その場合、図２２３、図２２５におけるコマンドの第２行目の先頭は、Sr（REPEATED START condition）ではなく、S（START condition）であってもよい。その場合、図２２３、図２２５におけるコマンド例の第１行目は省略されてもよい。
　図２２３の書き込み命令は２行分の書き込みデータ（WRITE DATA）が送信される例であるが、１行分のみまたは３行分以上の書き込みデータ（WRITE DATA）が送信されるように構成されてもよい。図２２５の読み出し命令および読み出し応答は１行分の書き込みデータ（WRITE DATA）および１行分の読み出しデータ（READ DATA）が送信される例であるが、書き込みデータ（WRITE DATA）の送信が省略されるように構成されてもよいし、図２２５におけるコマンド例の第３行目および第４行目が繰り返し送信（ただし、各行に格納されるアドレスまたはデータの一部または全部は異なってもよい）されることによって２行分以上の読み出しデータ（READ DATA）が送信されるように構成されてもよい。図２２３の書き込み命令の一部または全部と図２２５の読み出し命令および読み出し応答の一部または全部とが組み合わせて送信されるように構成されてもよい。
　書き込みデータ（WRITE DATA）または読み出しデータ（READ DATA）の全部を暗号化OFF領域としてもよいし、書き込みデータ（WRITE DATA）または読み出しデータ（READ DATA）の全部を暗号化ON領域としてもよい。書き込みデータ（WRITE DATA）または読み出しデータ（READ DATA）の一部を暗号化OFF領域とし、書き込みデータ（WRITE DATA）または読み出しデータ（READ DATA）の残りの一部または全部を暗号化ON領域としてもよい。
　例えば、CBC modeで暗号化する場合、暗号化ON領域（メッセージ認証対象であることが望ましい）よりも前の暗号化OFF領域（メッセージ認証対象であることが望ましい）の一部または全部において、CBC modeによる暗号化で用いられる、乱数で構成される初期化ベクトルの値（例えば、16バイト分）が送信されることが望ましい。例えば、Control planeに用いられる拡張パケットヘッダ（EXTENDED HEADER）の次の行（図２２３または図２２５における２行目）の一部または全部において、CBC modeによる暗号化で用いられる、乱数で構成される初期化ベクトルの値（例えば、16バイト分）が送信されるように構成されてもよい。
　この場合、図２２３における３行目のWRITE DATAの一部または全部がCBC modeによって暗号化されてもよいし、図２２３における４行目のREAD DATAの一部または全部がCBC modeによって暗号化されてもよい。この場合、CCIのMaster側が初期化ベクトルの値を送信するので、CCIのMaster側は初期化ベクトル用に乱数を生成する必要がある。一方、CCIのSlave側（例えば、イメージセンサ）は初期化ベクトル用に乱数を生成する必要がない。
　ただし、CBC modeによる暗号化で用いられる、乱数で構成される初期化ベクトルの値（例えば、16バイト分）は、READ DATAに格納されて送信されるように構成されてもよい。その場合には、CCIのSlave側（例えば、イメージセンサ）は初期化ベクトル用に乱数を生成する必要がある。CBC mode以外による暗号化であれば、乱数で構成される初期化ベクトルの値が送信される必要はない。暗号化OFF領域と暗号化ON領域との定義または指定は、Control planeまたはData planeに用いられる拡張パケットヘッダによってなされてもよい。また、暗号化OFF領域と暗号化ON領域との定義または指定は、通信ホストと通信デバイスとの間の事前合意（Private contract）によってなされてもよい。これによって、複数のアルゴリズムオプションの中から選択された、実装されたアルゴリズムに応じて好適なフォーマットを選択可能になる。例えば、Vendor defined SPDMメッセージによって送信されたアルゴリズム情報の一部または全部がCBC modeに関連する情報である場合、Control plane hostまたはControl plane deviceは、そのアルゴリズム情報が受信された以降にControl planeセッションで受信されるデータはCBC modeで暗号化されていると判断することが可能である。つまり、Control plane hostまたはControl plane deviceは、Vendor defined SPDMメッセージによって送信されたアルゴリズム情報に応じて、CBC modeによる暗号化で用いられる、乱数で構成される初期化ベクトルの値を送信するか否かを判断して回路または処理を切り替えてもよいし、乱数で構成される初期化ベクトルの値が送信されているか否かを判断して回路または処理を切り替えてもよい。Control plane hostまたはControl plane deviceは、Control planeに用いられる拡張パケットヘッダ（例えば、Service Descriptor）による定義または指定に応じて、CBC modeによる暗号化で用いられる、乱数で構成される初期化ベクトルの値を送信するか否かを判断して回路または処理を切り替えてもよいし、乱数で構成される初期化ベクトルの値が送信されているか否かを判断して回路または処理を切り替えてもよい。ただし、Control planeに用いられる拡張パケットヘッダによる定義または指定は、セキュリティ機能の有無（ON/OFF）、暗号化の有無（ON/OFF）、CBC modeの有無（ON/OFF）、乱数送信の有無（ON/OFF）、または初期化ベクトル送信の有無（ON/OFF）などであってもよい。Control planeセッションのメッセージ（データ）が暗号化される場合について説明したが、それらの一部または全部はVendor defined SPDMメッセージ（データ）が暗号化される場合にも適用でき、例えば、Control planeとして説明した内容のControl planeを含む表現の一部または全部はSPDMを含む表現に置き換えられてもよい。Control planeとして説明した内容の一部または全部をData planeに適用できる場合もあり、Data planeとして説明した内容の一部または全部をControl planeに適用できる場合もあるので、Control planeとして説明した内容のControl planeを含む表現の一部または全部はData planeを含む表現に置き換えられてもよいし、Data planeとして説明した内容のData planeを含む表現の一部または全部はControl planeを含む表現に置き換えられてもよい。図２２３または図２２５におけるREG ADDRESS（レジスタアドレス）は、一部のREG ADDRESSと他のREG ADDRESSとでアドレスが同一であってもよいし、一部のREG ADDRESSと他のREG ADDRESSとでアドレスが異なってもよい。
　Control planeに用いられる拡張パケットヘッダは、ESS CCI Service Descriptorの一部または全部を含む表現で称されてもよい。Control planeに用いられる拡張パケットヘッダには、Security Descriptorの一部またはService Descriptorの一部に相当する定義が格納されてもよい。Control planeに用いられる拡張パケットヘッダは、例示した合計1バイトとなる定義だけではなく、合計2バイト以上となるように定義されてもよい。
　Control planeに用いられる拡張パケットヘッダ（例えば、拡張ヘッダ、EXTENDED HEADER）によって、現在使用しているセッション鍵（もちろん、新セッション鍵などであってもよい）または次に使用するセッション鍵がEven鍵またはOdd鍵なのかが指定されてもよい。つまり、Control planeに用いられる拡張パケットヘッダは、セッション鍵に関連する情報を含んでもよいし、セッション鍵がEven鍵およびOdd鍵の何れなのかに関連する情報を含んでもよい。Control planeに用いられる拡張パケットヘッダの指定に応じて、Even鍵またはOdd鍵は破棄または上書きされてもよい。
　ESS CCI（Enhanced Safety and Security Camera Control Interface）またはACMP（A-PHY Control & Management Protocol）などの様なControl planeに用いられるメッセージカウンタは、0バイトまたは1バイトをデフォルト値として、それ以上に増やせるように構成されてもよい。Control planeに用いられるメッセージカウンタは、機能安全のみ対応の場合は1バイトを送信できるようにし、セキュリティ対応の場合には1バイト以上を送信できるようにしてもよい。Control planeに用いられるセッション鍵は、Control plane向けメッセージカウンタが１周する前までに更新されればよい。
　図２２３または図２２５におけるSTART conditionからMAC n-1 [7:0]の前までに送信されるメッセージの一部または全部が、メッセージ認証対象（MAC計算の対象となり、メッセージ認証によって保護されるメッセージ）である。図２２３または図２２５は、Control planeに用いられるメッセージカウンタの全部を送信する例である。しかし、Control planeに用いられるメッセージカウンタの全部をCMACまたはHMAC（またはGMACまたはGCM）のメッセージ認証対象とし、Control planeに用いられるメッセージカウンタの一部を送信する（一部を送信しない）ように構成されてもよい。つまり、Control planeに用いられるメッセージカウンタは、例えば8ビット（1バイト）のControl planeメッセージカウンタと、Control planeメッセージカウンタに応じて変化（例えば、インクリメントまたはデクリメント）するControl plane追加メッセージカウンタとによって構成されてもよい。このとき、Control planeメッセージカウンタの値およびControl plane追加メッセージカウンタの値がCMACまたはHMAC（またはGMACまたはGCM）のメッセージ認証対象の一部であってもよい。さらに、Control planeメッセージカウンタの値はControl planeセッションで送信されるが、Control plane追加メッセージカウンタの値はControl planeセッションで送信されない（つまり、暗黙的なメッセージとなる）ように構成されてもよい。
　例えば、Control planeメッセージカウンタがControl planeに用いられるメッセージカウンタのLSB（Least Significant Bit）側、Control plane追加メッセージカウンタがControl planeに用いられるメッセージカウンタのMSB（Most Significant Bit）側であってもよい。LSB側とMSB側とは逆であってもよい。同様に、Data planeに用いられるメッセージカウンタは、例えば16ビットのData planeメッセージカウンタと、Data planeメッセージカウンタに応じて変化（例えば、インクリメントまたはデクリメント）するData plane追加メッセージカウンタとによって構成される。このとき、Data planeメッセージカウンタの値およびData plane追加メッセージカウンタの値がCMACまたはHMAC（またはGMACまたはGCM）のメッセージ認証対象の一部であってもよい。さらに、Data planeメッセージカウンタの値はData planeセッションで送信されるが、Data plane追加メッセージカウンタの値はData planeセッションで送信されない（つまり、暗黙的なメッセージとなる）ように構成されてもよい。
　例えば、Data planeメッセージカウンタがData planeに用いられるメッセージカウンタのLSB（Least Significant Bit）側、Data plane追加メッセージカウンタがData planeに用いられるメッセージカウンタのMSB（Most Significant Bit）側であってもよい。LSB側とMSB側とは逆であってもよい。送信するまたは送信された明示的なメッセージであるControl planeメッセージまたはData planeメッセージの途中に暗黙的なメッセージが挿入された、明示的なメッセージおよび暗黙的なメッセージで構成されるメッセージ認証対象のMAC値が計算されてもよい。なお、上記の「途中」は、例えば、Control planeメッセージカウンタまたはData planeメッセージカウンタの値の前後を指している。上記の「暗黙的なメッセージ」は、例えば、Control plane追加メッセージカウンタまたはData plane追加メッセージカウンタの値を指している。
　送信するまたは送信された明示的なメッセージであるControl planeメッセージまたはData planeメッセージの前後に暗黙的なメッセージが挿入された、明示的なメッセージおよび暗黙的なメッセージで構成されるメッセージ認証対象のMAC値が計算されてもよい。これらの場合にも、リプレイ攻撃は対策される。なお、上記の「Control planeメッセージまたはData planeメッセージの前後」は、例えば、明示的なメッセージの直前、明示的なメッセージとMAC n-1 [7:0]メッセージまたはePF1メッセージとの間を指している。上記の「暗黙的なメッセージ」は、例えば、Control plane追加メッセージカウンタまたはData plane追加メッセージカウンタの値を指している。
　上述した通り、CMACまたはHMACでは追加メッセージカウンタの値をメッセージ認証対象に含めてリプレイ攻撃を対策することが望ましい。しかし、GMACまたはGCMでは追加メッセージカウンタの値をメッセージ認証対象に含める必要はなく、GMACまたはGCMでは追加メッセージカウンタの値を初期化ベクトルに含めることが望ましい。そこで、MACアルゴリズムがCMACまたはHMACである場合、追加メッセージカウンタの値の一部または全部がメッセージ認証対象として含められる。MACアルゴリズムがGMACまたはGCMである場合、追加メッセージカウンタの値の一部または全部が少なくとも初期化ベクトルに含められるように構成された保護部の存在が、最少で1つの追加メッセージカウンタだけでも（複数の追加メッセージカウンタを設けることなく）CMAC、HMAC、GMAC、およびGCMなどのMACアルゴリズムへの対応を可能にする。
　可変メッセージカウンタ（Variable message counter）は、固定メッセージカウンタ（拡張されたメッセージカウンタ）であってもよい。可変メッセージカウンタによるリプレイ攻撃対策を説明した。固定メッセージカウンタである場合には追加メッセージカウンタによるリプレイ攻撃対策だと解釈すればよい。
　CCI-MAC tag lengthは、12バイトであってもよい。例えば、CCI_MACのFieldにおいて、0b000: CCI-MAC tag length is 04 bytes、0b001 : CCI-MAC tag length is 08 bytes、0b010 : CCI-MAC tag length is 12 bytes、と定義されてもよい。
　SPDMセッション、Control planeセッション、またはData planeセッションのメッセージ認証または暗号化（または復号）に乱数の初期化ベクトルが用いられるとする。この場合、例えばVendor defined SPDMメッセージ（例えば、VENDOR_DEFINED_REQUEST要求メッセージまたはVENDOR_DEFINED_RESPONSE応答メッセージ）によって初期化ベクトルが送信されてもよい。
　Vendor defined SPDMメッセージ、VENDOR_DEFINED_REQUEST要求、またはVENDOR_DEFINED_RESPONSE応答によって送信されるメッセージとして説明したメッセージの一部または全部は、DMTFが発行するDSP0277（Secured Messages using SPDM）仕様に準拠するSecured Messageとして送信されてもよい。また、DMTF以外の標準化団体（例えば、MIPIアライアンス）またはVendorによってDSP0277仕様の一部または全部が変更されたVendor defined Secured Message（DSP0277仕様に準拠または非準拠）として送信されてもよい。このとき、上記「メッセージの一部または全部」は、このSecured MessageはVendor defined SPDMメッセージ、VENDOR_DEFINED_REQUEST要求、またはVENDOR_DEFINED_RESPONSE応答であると解釈してもよい。Vendor defined SPDMメッセージ、VENDOR_DEFINED_REQUEST要求、またはVENDOR_DEFINED_RESPONSE応答によって送信されるメッセージとして説明したメッセージの一部または全部は、SPDMセッションではなく保護されたControl planeセッションで送信されてもよい。DSP0277仕様に準拠するSecured Messageは、AES-128-GCM、AES-256-GCM、またはCHACHA20_POLY1305などのAEADアルゴリズムに対応するフォーマットである。DSP0277仕様に準拠するSecured Messageは、MACアルゴリズム（例えば、GMAC、CMAC、HMAC）と暗号化アルゴリズム（例えば、CTR mode、CBC mode）との組み合わせに対応していない。そのため、MACアルゴリズムと暗号化アルゴリズムとの組み合わせも対応するようにDSP0277仕様の一部または全部が変更されてもよい。Secured Message formatは、Session ID（4 Bytes）、Sequence Number（Variable）、Length（2 Bytes）、Application Data Length（2 bytes）、Application Data（Variable Bytes）、Random Data（Variable Bytes）、およびMessage Authentication Code（MAC Length）の順で構成される。Session IDとSequence NumberとLengthとは、メッセージ認証対象（MAC Coverage）かつ平文（Clear Text）かつヘッダである。Application Data Lengthはメッセージ認証対象かつ暗号化対象（Encrypted Data）かつヘッダである。Application DataとRandom Dataとはメッセージ認証対象かつ暗号化対象である。メッセージ認証対象かつ平文かつヘッダの領域にベンダ固有領域（Vendor specific）、ベンダ定義領域（Vendor Defined）、ユーザ定義領域（User Defined）、またはリザーブド領域（Reserved for future use）などが追加されてもよい。CBC modeによる暗号化で用いられる、乱数で構成される初期化ベクトルの値が格納されて送信されることが可能になる。Secured Message formatは、何れかの追加領域を設けることでCBC modeに対応するフォーマットとなる。SPDMリクエスタまたはSPDMレスポンダは、例えばNEGOTIATE_ALGORITHMS要求およびALGORITHMS応答などによって、SPDMリクエスタとSPDMレスポンダとの間で選択されたSPDMセッション向けアルゴリズムに応じて、対応するSecured Message formatを切り替えてもよいし、対応するSecured Message formatの一部または全部を変更してもよい。SPDMリクエスタまたはSPDMレスポンダは、例えばNEGOTIATE_ALGORITHMS要求およびALGORITHMS応答などによって、SPDMリクエスタとSPDMレスポンダとの間で選択されたSPDMセッション向けアルゴリズムに応じて、CBC modeによる暗号化で用いられる、乱数で構成される初期化ベクトルの値を送信するか否かを判断して回路または処理を切り替えてもよいし、乱数で構成される初期化ベクトルの値が送信されているか否かを判断して回路または処理を切り替えてもよい。
　初期化ベクトル構成は、ベンダ固有（Vendor specific）またはベンダ定義（Vendor defined）のビット領域を含んでもよい。初期化ベクトル構成のベンダ固有領域またはベンダ定義領域には、図９６、図１０２、図１０７、図１１３、または図２１８（Ｂ）などを用いて上述した初期化ベクトル構成の一部または全部が割り当てられてもよい。例えば、初期化ベクトル構成のベンダ固有領域またはベンダ定義領域は、拡張仮想チャネルeVCまたは仮想チャネルVCを含んでもよい。
　互いに異なる暗号化鍵とMAC鍵とは、それぞれがVendor defined SPDMメッセージなどで送信されてもよい。また、互いに異なる暗号化鍵とMAC鍵とは、Vendor defined SPDMメッセージなどで送信するまたは送信される1つのセッション鍵またはセッション秘密からそれぞれが導出されてもよい。
　National Institute of Standards and Technologyが発行するSpecial Publication 800-108（Recommendation for Key Derivation Using Pseudorandom Functions）では、KDF（Key Derivation Function）using HMACおよびKDF using CMACが定義されている。上述したSPDM鍵スケジュールではKDF using HMACに基づいて鍵スケジュールが構成されている。KDF using CMACに基づいて構成される鍵スケジュールが上述したSPDM鍵スケジュールの代わりに適用（ただし、SPDMに準拠であってもよいし、SPDMに非準拠であってもよい）されてもよい。以下の（１）～（４）が、それぞれ適用される場合、これらによって構成されるシステムはAESのみで構成され、Resource constrained sensorに特に好適である。ただし、これらの一部または全部の代わりにGCM、GMAC、またはHMACが適用されてもよい。また、これらの一部または全部の暗号化機能が省略（メッセージ認証機能のみ）されてもよい。CTRモードはCBCモードよりも通信のオーバーヘッドが少なくて高速化も可能な利点があり、CBCモードはCTRモードよりも初期化ベクトルの管理が容易な利点があるので、Individual modeのControl planeセッションにはブロック暗号CBCモードとCMACとの組み合わせが、Running modeのControl planeセッションにはブロック暗号CTRモードとCMACとの組み合わせが、Data planeセッションにはブロック暗号CTRモードとCMACとの組み合わせが、それぞれ特に好適な場合もある。SPDMセッションとControl planeセッションとでは、一部または全部が同じ暗号アルゴリズム（暗号化アルゴリズム、メッセージ認証アルゴリズム、またはAEADアルゴリズム）の適用されたセキュリティ演算部の一部または全部が共用されてもよい。SPDMセッションとData planeセッションとについても同様であり、Control planeセッションとData planeセッションとについても同様であるが、SPDMセッションとControl planeセッションとはそれぞれ同じプロトコル（例えば、CCI）を一部または全部に含んで構成可能なので特に共用しやすい。
（１）SPDM鍵スケジュールにKDF using CMACに基づいて構成される鍵スケジュール
（２）SPDMセッションにブロック暗号CBCモードまたはブロック暗号CTRモードの何れかとCMACとの組み合わせ
（３）Control planeセッションにブロック暗号CBCモードまたはブロック暗号CTRモードの何れかとCMACとの組み合わせ
（４）Data planeセッションにブロック暗号CBCモードまたはブロック暗号CTRモードの何れかとCMACとの組み合わせ
＜リプレイ攻撃対策例＞
　次に、リプレイ攻撃対策例について説明する。
　例えば、GMC,CCM,GMACに用いられる十分に長い時間ユニークな初期化ベクトルIVは、リプレイ攻撃対策となり得る（図２２６の太枠内）。図２２７は、Data planeに対するGMAC,GCMの適用例を示したものである。図２２８は、図２２７の用語を説明する図である。画像データのラインごとに設けられた拡張パケットヘッダePH内には、メッセージカウンタMCが含まれており、そのメッセージカウンタMCが一周する期間（１フレーム期間）を超えて、初期化ベクトル値IVを１ずつインクリメントした値がLine-MAC値として用いられる。Line-MAC値は、各ラインにおいて、画像データ等のラインデータとパケットフッタとの間に設けられている。このようにすることで、リプレイ攻撃を不可能にすることが可能となる。
　例えば、GMC,CCM,GMACに用いられる十分に長い時間ユニークな初期化ベクトルIVは、リプレイ攻撃対策となり得る（図２２９の太枠内）。図２３０は、Data planeに対するGMAC,GCMの適用例を示したものである。画像データのフレームごとに、初期化ベクトル値IVを１ずつインクリメントした値がFrame-MAC値として設けられている。Frame-MAC値は、各フレームにおいて、パケットフッタPFに設けられている。
　例えば、CMAC,HMACまたはGMACに用いられるFrame-MACは、リプレイ攻撃対策となり得る（図２３１の太枠内）。図２３１は、Data planeに対するCMACの適用例を示したものである。図２３２は、Data planeに対するCMACおよびCTRモードの適用例を示したものである。CMACをHMACまたはGMACに置き換えることも可能である。図２３３は、図２３２の用語を説明する図である。画像データのフレームごとに、１または複数の埋め込みデータ（embedded data）が設けられ、埋め込みデータに含まれるナンス値がメッセージ認証対象に含まれるFrame-MAC値（CMAC）として設けられる。埋め込みデータは、例えば、画像データとフレームスタートとの間、または、画像データとフレームエンドとの間に設けられる。
　埋め込みデータは、追加フレーム番号を含んでもよいし、フレームごとに変化するカウント値または乱数の一部もしくは全部、すなわち、ナンス値の一部もしくは全部を含んでもよい。CBCモードまたはＣＴＲモードのいずれかと、GMAC、HMACまたはCMACとを組み合わせる場合、GCMもしくはCCMと比較して、拡張パケットヘッダ（例えば、Service Descriptor）を利用して自由に暗号化をON/OFFできる。CTR modeによる暗号化は、GMAC、HMACまたはCMACのようなMACアルゴリズムによるメッセージ認証と組み合わせて使用しないと狙ったビットをフリップすること（暗号文のビット反転攻撃）が可能になるので、CTR modeはGMAC、HMACまたはCMACのようなMACアルゴリズムと組み合わせて使用されることが望ましい。CBC modeによる暗号化は、CTR modeによる暗号化よりも暗号文のビット反転攻撃に対する耐性は高いが完全ではなく、改竄を検出するために、GMAC、HMACまたはCMACのようなMACアルゴリズムによるメッセージ認証と組み合わせて使用されることが望ましい。図２２７、図２３０、または図２３２におけるSA1とSA2とは、同一なSAまたは同一番号のSAとして定義され、拡張パケットヘッダ（例えば、Service Descriptor）内のフラグ（ビットフラグ）を利用して暗号化のON/OFFが切り替えられてもよい。MAC値の計算、送信、または受信は、図２２７で例示したライン単位または図２３０および図２３２で例示したフレーム単位ではなく、複数ライン単位であってもよい。画像データまたは埋込データは、全部ではなく一部がメッセージ認証対象であってもよい。
　GCMまたはCCMの場合、「メッセージ認証のみの対象領域→メッセージ認証および暗号化の対象領域→MAC格納領域」の順番を満たす必要がある。そのため、GCMまたはCCMには、画像データ（Img Data）のみをメッセージ認証および暗号化の対象領域とし、拡張パケットヘッダをメッセージ認証のみの対象領域とすることができない。一方で、ブロック暗号CBCモードまたはブロック暗号CTRモードの何れか（暗号化）と、GMAC、HMACまたはCMACの何れか（メッセージ認証）とを組み合わせることにより、画像データ（Img Data）のみをメッセージ認証および暗号化の対象領域とし、拡張パケットヘッダをメッセージ認証のみの対象領域とすることができる。同様に、画像データではなく任意データのみをメッセージ認証および暗号化の対象領域とし、他の任意データをメッセージ認証のみの対象領域とすることができる、つまり、Partial encryptionが可能である。
（Control planeセッション）
　図２３４、図２３５、図２３６、図２３７は、通信システム３１００におけるControl planeセッションのフローチャート例を示したものである。図２３５のフローは、図２３４に続くフローである。
　まず、通信システム３１００は、通信制御部３１１０ａと、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、センサ部３１２０ａまたはブリッジ他端３１２０ｂとの間にSPDMセッションを確立する（ステップＳ３１０１，３２０１，３３０１）。次に、通信制御部３１１０ａは、セッション鍵を生成する（ステップＳ３１０２）。
　次に、通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージまたは書き込み命令によって、Control planeセッション開始要求を通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに送信する。通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション開始要求を受信する（ステップＳ３２０３；Ｙ）。すると、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション開始要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージ、ERROR応答メッセージ、または読み出し応答によって、Control planeセッション開始応答を通信制御部３１１０ａに送信してもよい。ただし、例えば、アルゴリズム情報、他パラメータ情報およびControl planeセッション鍵（MAC鍵または暗号化鍵）の受信完了、またはControl planeセッション鍵（MAC鍵または暗号化鍵）の受信完了をControl planeセッション開始要求と解釈することなどによって、Control planeセッション開始要求の送信および受信が省略されてもよい。
　通信制御部３１１０ａが、先にControl plane deviceであるセンサ部３１２０ａまたはブリッジ他端３１２０ｂに、アルゴリズム情報、他パラメータ情報およびControl planeセッション鍵を送信し、その後にControl plane hostである通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに、アルゴリズム情報、他パラメータ情報およびControl planeセッション鍵を送信してもよい（ステップＳ３１０３，Ｓ３１０４）。この場合、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、通信制御部３１１０ａから、アルゴリズム情報、他パラメータ情報およびControl planeセッション鍵を受信する（ステップＳ３３０２；Ｙ）。また、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、通信制御部３１１０ａから、アルゴリズム情報、他パラメータ情報およびControl planeセッション鍵を受信する（ステップＳ３２０２；Ｙ）。その結果、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、センサ部３１２０ａまたはブリッジ他端３１２０ｂが既に同じControl planeセッション鍵を持っているか否かを気にしないで、Control planeセッション（Control planeセッション鍵の使用）を開始できる（ステップＳ３２０４）。なお、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、例えば、アルゴリズム情報、他パラメータ情報およびControl planeセッション鍵の受信完了、またはControl planeセッション鍵（MAC鍵または暗号化鍵）の受信完了をControl planeセッション開始要求と解釈してもよい（ステップＳ３２０３）。
　一方、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、通信制御部３１１０ａから、アルゴリズム情報、他パラメータ情報およびControl planeセッション鍵を受信した後、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂが既に同じControl planeセッション鍵を持っているか否かを気にしないで、Control planeセッション（Control planeセッション鍵の使用）を開始できる（ステップＳ３３０４）。なお、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、通信制御部３１１０ａから、CCI拡張ヘッダ（EXTENDED HEADER）を受信した上で、Control planeセッション（Control planeセッション鍵の使用）を開始してもよい（ステップＳ３３０３；Ｙ）。この場合、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、CCIメッセージカウンタのバイト幅もしくはビット幅を設定することができる。
　逆に、通信制御部３１１０ａが、先にControl plane hostである通信制御部３１１０ｃまたはブリッジ一端３１１０ｂにControl planeセッション鍵を送信し、その後にControl plane deviceであるセンサ部３１２０ａまたはブリッジ他端３１２０ｂにControl planeセッション鍵を送信してもよい。この場合、通信制御部３１１０ａが通信制御部３１１０ｃまたはブリッジ一端３１１０ｂにControl planeセッション開始要求を送信することによって、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、センサ部３１２０ａまたはブリッジ他端３１２０ｂが既に同じControl planeセッション鍵を持っていると判断できる。その結果、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション（Control planeセッション鍵の使用）を開始できる（ステップＳ３２０４）。
　なお、フローチャートでは省略されているが、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション鍵によって保護された書き込み命令または読み出し命令を適切なタイミングで送信する。さらに、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Control planeセッション鍵によって保護された読み出し応答を適切なタイミングで送信する。
　通信制御部３１１０ａは、複数のControl planeセッション鍵（MAC鍵または暗号化鍵）を保持してもよい。「アルゴリズム情報、他パラメータ情報、およびセッション鍵の送信」と「セッション鍵の送信」とは、例えばVendor defined SPDMメッセージ（例えば、VENDOR_DEFINED_REQUEST要求メッセージまたはVENDOR_DEFINED_RESPONSE応答メッセージ）によって送信される。通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージによってアルゴリズム情報、他パラメータ情報、またはControl planeセッション鍵を送信する。通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージを送信した場合、要求メッセージが通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａで正常に受信または処理されたことを示すVENDOR_DEFINED_RESPONSE応答メッセージの受信に応じて次のステップに進んでもよい。
　また、通信制御部３１１０ａは、例えば、要求メッセージが通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａで正常に受信または処理されていないことを示すVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージを受信したとする。この場合、通信制御部３１１０ａは、例えば、必要に応じてVENDOR_DEFINED_REQUEST要求メッセージを再送してもよく、同じControl planeセッション鍵または再生成した異なるControl planeセッション鍵を送信してもよい。
　一方、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、VENDOR_DEFINED_REQUEST要求メッセージが正常に受信または処理された場合、正常に受信または処理されたことを示すVENDOR_DEFINED_RESPONSE応答メッセージを送信した後に次のステップに進んでもよい。また、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、VENDOR_DEFINED_REQUEST要求メッセージが正常に受信または処理されなかった場合、そのことを示すVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージを送信してもよく、SSMCにVENDOR_DEFINED_REQUEST要求メッセージの再送を要求してもよい。また、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、要求メッセージの処理が所定時間内に完了しなかった場合にも、そのことを示すVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージを送信してもよく、SSMCにVENDOR_DEFINED_REQUEST要求メッセージの再送を要求してもよい。
　通信制御部３１１０ａは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂと、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａとで、使用しているControl planeセッション鍵を更新する必要があるのか否かを把握する。通信制御部３１１０ａは、そのために、VENDOR_DEFINED_REQUEST要求メッセージによって、Control planeセッション鍵確認要求を定期的に、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに送信する（ステップＳ３１０６）。
　通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、通信制御部３１１０ａからControl planeセッション鍵確認要求を受信する（ステップＳ３２０５；Ｙ）。すると、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション鍵確認要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージによって、Control planeセッション鍵確認応答を通信制御部３１１０ａに送信する（ステップＳ３２０８）。ここで、Control planeセッション鍵確認応答は、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂと、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａとで使用しているControl planeセッション鍵を更新する必要がある否かを示す情報、または、Control planeセッション鍵の使用回数（例えば、MAC値の計算回数）を示す情報などを含む。
　通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、VENDOR_DEFINED_REQUEST要求メッセージによってControl planeセッション鍵確認要求を受信したとき、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂがControl planeセッション鍵を使用中であるとする。このとき、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、VENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージの送信によってControl planeセッション鍵確認要求の再送を通信制御部３１１０ａに要求してもよい。
　通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション鍵を更新したいとする。この場合、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂがControl planeセッション鍵を使用していないタイミング（例えば、MAC値の計算を完了し、Control planeセッション鍵の使用を終了した後）で、通信制御部３１１０ａにControl planeセッション鍵の送信を要求することが望ましい（ステップＳ３２０７）。このとき、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、VENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージによって、通信制御部３１１０ａにControl planeセッション鍵の送信要求（例えば、Control planeセッション鍵確認応答）を行うことが可能である（ステップＳ３２０８）。
　通信制御部３１１０ａは、Control planeセッション鍵の送信要求（例えば、Control planeセッション鍵確認応答）を受信する（ステップＳ３１１１）。すると、通信制御部３１１０ａは、Control planeセッションを更新する必要がある場合、新たなControl planeセッション鍵を生成する（ステップＳ３１１２；Ｙ，Ｓ３１１３）。通信制御部３１１０ａは、生成した新たなControl planeセッション鍵を、センサ部３１２０ａ、ブリッジ他端３１２０ｂ、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに送信する（ステップＳ３１１４，Ｓ３１１５）。その後、通信制御部３１１０ａは、Control planeセッション開始要求を、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに送信する（ステップＳ３１１６）。
　通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション鍵の送信要求（例えば、Control planeセッション鍵確認応答）の応答として、Control planeセッション鍵を通信制御部３１１０ａから受信する（ステップＳ３２０９；Ｙ）。通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション鍵を受信すると、Control planeセッション鍵を更新する（ステップＳ３２１０）。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Control planeセッション鍵を通信制御部３１１０ａから受信する（ステップＳ３３０５；Ｙ）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Control planeセッション鍵を受信すると、Control planeセッション鍵を更新する（ステップＳ３３０６）。
　通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージによって、Control planeセッションの終了を要求するControl planeセッション終了要求を、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに送信してもよい（ステップＳ３１０８）。このとき、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Control planeセッション終了要求に応じたVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージによって、Control planeセッションの終了の可否を応答するControl planeセッション終了応答を通信制御部３１１０ａに送信してもよい。
　通信制御部３１１０ａは、さらに、VENDOR_DEFINED_REQUEST要求メッセージによって、Control planeセッション終了要求を、センサ部３１２０ａまたはブリッジ他端３１２０ｂに送信してもよい（ステップＳ３１０９）。このとき、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Control planeセッション終了要求に応じたVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージによって、Control planeセッションの終了の可否を応答するControl planeセッション終了応答を通信制御部３１１０ａに送信してもよい。
　通信制御部３１１０ａは、Control planeセッションを終了させる場合、先にControl plane hostである通信制御部３１１０ｃまたはブリッジ一端３１１０ｂにControl planeセッション終了要求を送信する。そして、通信制御部３１１０ａは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂによるControl planeセッション鍵の使用を終了させる。その後に、通信制御部３１１０ａは、Control plane deviceであるセンサ部３１２０ａまたはブリッジ他端３１２０ｂにControl planeセッション終了要求を送信する。そして、通信制御部３１１０ａは、センサ部３１２０ａまたはブリッジ他端３１２０ｂによるControl planeセッション鍵の使用を終了させる。この順番の場合、早急または安全にセッションが終了される。
　通信制御部３１１０ａ、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、セッションの終了の際に、Control planeセッション鍵を破棄またはクリーンアップする（ステップＳ３１１０，Ｓ３２１３，Ｓ３３０９）。このようにして、通信システム３１００におけるControl planeセッションが実行される。
（Data planeセッション）
　図２３８、図２３９、図２４０、図２４１は、通信システム３１００におけるData planeセッションのフローチャート例を示したものである。図２３９のフローは、図２３８に続くフローである。
　まず、通信システム３１００は、通信制御部３１１０ａと、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、センサ部３１２０ａ、またはブリッジ他端３１２０ｂとの間にSPDMセッションを確立する（ステップＳ３４０１，３５０１，３６０１）。次に、通信制御部３１１０ａは、Even鍵およびOdd鍵を生成する（ステップＳ３４０２）。
　次に、通信システム３１００は、VENDOR_DEFINED_REQUEST要求メッセージまたは書き込み命令によって、Data planeセッション開始要求をセンサ部３１２０ａまたはブリッジ他端３１２０ｂに送信する（ステップＳ３４０５）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Data planeセッション開始要求を受信する（ステップＳ３６０３；Ｙ）。すると、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Data planeセッション開始要求に応じたVENDOR_DEFINED_RESPONSE応答メッセージ、ERROR応答メッセージ、または読み出し応答によって、Data planeセッション開始応答を通信制御部３１１０ａに送信してもよい。
　ただし、Data planeセッション開始要求は、画像データ送信開始要求または高速データ送信開始要求であってもよい。また、例えば、「アルゴリズム情報、他パラメータ情報、Even鍵およびOdd鍵」の受信完了をData planeセッション開始要求と解釈することなどによって、Data planeセッション開始要求の送信および受信が省略されてもよい。SPDMセッションが確立された直後の「Odd鍵の生成」、「Odd鍵の送信」および「Odd鍵の受信」は省略されてもよい。
　Even鍵は、Data planeセッション鍵であって、暗号化鍵およびMAC鍵のうちの少なくとも何れかである。同様に、Odd鍵は、Data planeセッション鍵であって、暗号化鍵およびMAC鍵のうちの少なくとも何れかである。フローチャートにおけるEven鍵とOdd鍵との表現は、Even鍵/Odd鍵を逆転させても構わない。Even鍵またはOdd鍵は、Key 0、Key 1、Key 2、Key 3、またはKey 4の何れかとして称されてもよい。
　通信制御部３１１０ａは、先にData plane hostである通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに、アルゴリズム情報、他パラメータ情報およびData planeセッション鍵を送信する（ステップＳ３４０３）。その後、通信制御部３１１０ａは、Data plane deviceであるセンサ部３１２０ａまたはブリッジ他端３１２０ｂに、アルゴリズム情報、他パラメータ情報およびData planeセッション鍵を送信する（ステップＳ３４０４）。この場合、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、通信制御部３１１０ａから、アルゴリズム情報、他パラメータ情報およびData planeセッション鍵を受信する（ステップＳ３６０２；Ｙ）。また、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、通信制御部３１１０ａから、アルゴリズム情報、他パラメータ情報およびData planeセッション鍵を受信する（ステップＳ３５０２；Ｙ）。その結果、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂが既に同じData planeセッション鍵を持っているか否かを気にしないでData planeセッション（Data planeセッション鍵（フローチャートではEven鍵）の使用）を開始できる（ステップＳ３６０５）。
　逆に、通信制御部３１１０ａが、先にData plane deviceであるセンサ部３１２０ａまたはブリッジ他端３１２０ｂにData planeセッション鍵を送信し、その後にData plane hostである通信制御部３１１０ｃまたはブリッジ一端３１１０ｂにData planeセッション鍵を送信してもよい。この場合、通信制御部３１１０ａが、センサ部３１２０ａまたはブリッジ他端３１２０ｂにData planeセッション開始要求を送信することによって、センサ部３１２０ａまたはブリッジ他端３１２０ｂは通信制御部３１１０ｃまたはブリッジ一端３１１０ｂが既に同じData planeセッション鍵を持っていると判断できる。その結果、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Data planeセッション（Data planeセッション鍵（フローチャートではEven鍵）の使用）を開始できる（ステップＳ３６０５）。
　なお、フローチャートでは省略されているが、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、Even鍵またはOdd鍵によって保護された拡張パケット（例えば、フレームスタート、埋込データ、画像データ、ユーザ定義データ、フレームエンド）を適切なタイミングで送信する。
　通信制御部３１１０ａは、複数のEven鍵および複数のOdd鍵を保持してもよい。「アルゴリズム情報、他パラメータ情報、Even鍵、およびOdd鍵の送信」と「Even鍵の送信」と「Odd鍵の送信」とは、例えばVendor defined SPDMメッセージ（例えば、VENDOR_DEFINED_REQUEST要求メッセージまたはVENDOR_DEFINED_RESPONSE応答メッセージ）によって送信される。通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージによってアルゴリズム情報、他パラメータ情報、またはData planeセッション鍵を送信する。通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージを送信した場合、要求メッセージが通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａで正常に受信または処理されたことを示すVENDOR_DEFINED_RESPONSE応答メッセージの受信に応じて次のステップに進んでもよい。
　また、通信制御部３１１０ａは、例えば、要求メッセージが通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａで正常に受信または処理されていないことを示すVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージを受信したとする。この場合、通信制御部３１１０ａは、例えば、必要に応じてVENDOR_DEFINED_REQUEST要求メッセージを再送してもよく、同じData planeセッション鍵または再生成した異なるData planeセッション鍵を送信してもよい。
　一方、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、VENDOR_DEFINED_REQUEST要求メッセージが正常に受信または処理された場合、正常に受信または処理されたことを示すVENDOR_DEFINED_RESPONSE応答メッセージを送信した後に次のステップに進んでもよい。また、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、VENDOR_DEFINED_REQUEST要求メッセージが正常に受信または処理されなかった場合、そのことを示すVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージを送信してもよく、SSMCにVENDOR_DEFINED_REQUEST要求メッセージの再送を要求してもよい。また、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、要求メッセージの処理が所定時間内に完了しなかった場合、そのことを示すVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージを送信してもよく、SSMCにVENDOR_DEFINED_REQUEST要求メッセージの再送を要求してもよい。
　通信制御部３１１０ａは、VENDOR_DEFINED_REQUEST要求メッセージによって、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂの使用しているData planeセッション鍵がEven鍵なのかOdd鍵なのかを把握する。通信制御部３１１０ａは、そのために、Data planeセッション鍵確認要求を定期的に通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに送信する（ステップＳ３４０６，３４１３）。
　通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、通信制御部３１１０ａからData planeセッション鍵確認要求を受信する（ステップＳ３５１０，Ｓ３５１４；Ｙ）。すると、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Data planeセッション鍵確認要求に応じて、VENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージによって、Data planeセッション鍵確認応答を通信制御部３１１０ａに送信する（ステップＳ３５１１，Ｓ３５１５）。ここで、Data planeセッション鍵確認応答は、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂにおいて使用しているData planeセッション鍵がEven鍵なのかOdd鍵なのかを示す情報を含む。
　なお、Data planeセッション鍵確認要求は１フレーム毎または複数フレーム毎に定期的に送信されることが望ましく、Data planeセッション鍵確認応答はフレームブランキング期間またはラインブランキング期間に送信されることが望ましい。
　通信制御部３１１０ａは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂから、Data planeセッション鍵確認応答を受信する（ステップＳ３４０８，Ｓ３４１５）。Data planeセッション鍵確認応答に、Data planeセッション鍵がOdd鍵であることを示す情報が含まれる場合、通信制御部３１１０ａは、Even鍵を生成する（ステップＳ３４１０）。通信制御部３１１０ａは、生成したEven鍵を、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａに送信する（ステップＳ３４１１，Ｓ３４１２）。Data planeセッション鍵確認応答に、Data planeセッション鍵がEven鍵であることを示す情報が含まれる場合、通信制御部３１１０ａは、Odd鍵を生成する（ステップＳ３４１７）。通信制御部３１１０ａは、生成したOdd鍵を、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａに送信する（ステップＳ３４１８，Ｓ３４１９）。
　通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、通信制御部３１１０ａからEven鍵を受信する（ステップＳ３５０４；Ｙ，Ｓ３６１３；Ｙ）。すると、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、Data planeセッション鍵を、受信したEven鍵に更新する（ステップＳ３５０５，Ｓ３６１４）。通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、通信制御部３１１０ａからOdd鍵を受信する（ステップＳ３５０６；Ｙ，Ｓ３６０７；Ｙ）。すると、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、Data planeセッション鍵を、受信したOdd鍵に更新する（ステップＳ３５０７，Ｓ３６０８）。
　ブリッジ他端３１２０ｂまたはセンサ部３１２０ａは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに、Even鍵の使用開始タイミング指定を高速データ送信する（ステップＳ３６０６）。通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａから、Even鍵の使用開始タイミング指定を受信する（ステップＳ３５０８）。すると、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Even鍵の使用を開始する（ステップＳ３５０９）。ブリッジ他端３１２０ｂまたはセンサ部３１２０ａは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂに、Odd鍵の使用開始タイミング指定を高速データ送信する（ステップＳ３６１２）。通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａから、Odd鍵の使用開始タイミング指定を受信する（ステップＳ３５１２）。すると、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂは、Odd鍵の使用を開始する（ステップＳ３５１３）。
　通信制御部３１１０ａは、セッションの継続を終了する場合（ステップＳ３４０７，Ｓ３４１４；Ｙ）、VENDOR_DEFINED_REQUEST要求メッセージによってData planeセッション終了要求を通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａに送信する（ステップＳ３４２０，Ｓ３４２１）。通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂ、またはセンサ部３１２０ａは、Data planeセッション終了要求に応じたVENDOR_DEFINED_RESPONSE応答メッセージまたはERROR応答メッセージによってData planeセッション終了応答を通信制御部３１１０ａに送信する（ステップＳ３５１６，Ｓ３６１７）。
　通信制御部３１１０ａは、Data planeセッションを終了させる場合、先にData plane deviceであるセンサ部３１２０ａまたはブリッジ他端３１２０ｂにData planeセッション終了要求を送信する。そして、通信制御部３１１０ａは、センサ部３１２０ａまたはブリッジ他端３１２０ｂによるData planeセッション鍵の使用を終了させる。その後に、通信制御部３１１０ａは、Data plane hostである通信制御部３１１０ｃまたはブリッジ一端３１１０ｂにData planeセッション終了要求を送信する。そして、通信制御部３１１０ａは、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂによるData planeセッション鍵の使用を終了させる。この順番の場合、早急または安全にセッションが終了される。ところで、Control planeセッションについてControl planeセッション鍵が1つの例を用いて説明したが、Control planeセッション鍵もEven鍵とOdd鍵とで構成されてもよい。
　通信制御部３１１０ａ、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、セッションの終了の際に、Even鍵およびOdd鍵を破棄またはクリーンアップする（ステップＳ３４２２，Ｓ３５１７，Ｓ３６１８）。このようにして、通信システム３１００におけるData planeセッションが実行される。
　図２４２は、通信システム３１００の一変形例を表したものである。
　通信制御部３１１０ｃまたはブリッジ一端３１１０ｂが帯域内割込みを実行できてもよい。この場合、Control planeセッション鍵確認要求またはData planeセッション鍵確認要求が定期的に送信される必要はない。通信制御部３１１０ａは、帯域内割込みに応じてControl planeセッション鍵確認要求またはData planeセッション鍵確認要求を送信してもよい。また、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂが帯域内割込みとしてControl planeセッション鍵確認応答またはData planeセッション鍵確認応答を送信してもよい。この場合、Control planeセッション鍵確認要求またはData planeセッション鍵確認要求が省略され得る。
　また、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂ内に第２Control plane host（例えば、CCIマスタ）を追加し、通信制御部３１１０ａ内に第２Control plane device（例えば、CCIスレーブ）を追加してもよい。この場合、通信制御部３１１０ｃまたはブリッジ一端３１１０ｂから通信制御部３１１０ａへ、必要に応じて情報を送信できる。これにより、Control planeセッション鍵確認要求またはData planeセッション鍵確認要求が定期的に送信される必要がない。ただし、この第２Control plane hostと第２Control plane deviceとの間の通信は、少なくともメッセージ認証によって保護されていることが望ましいが、その限りではない。第１Control plane hostと第２Control plane hostとは、別体であってもよいし、一体であってもよい。また、第２Control plane hostをSPDMリクエスタと置き換え、第２Control plane deviceをSPDMレスポンダと置き換えてもよい。
　ところで、VENDOR_DEFINED_REQUEST要求メッセージまたはVENDOR_DEFINED_RESPONSE応答メッセージの他パラメータ情報は、Control planeメッセージカウンタ情報、Control planeメッセージ認証コード情報、Control planeソルト（乱数）情報、Control planeセッション鍵周期情報、Data planeメッセージ認証コード情報、Data planeソルト（乱数）情報、およびData planeセッション鍵周期情報のうちの少なくとも何れかを含んでもよい。セッション鍵周期情報は、通信制御部３１１０ａがセッション鍵を確認する周期（例えば、下限周期、標準周期、または上限周期）の情報であってもよい。また、セッション鍵周期情報は、通信制御部３１１０ｃ、ブリッジ一端３１１０ｂ、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａがセッション鍵を更新する周期（例えば、下限周期、標準周期、または上限周期）の情報であってもよい。
　Control planeセッション開始（要求または応答）、Control planeセッション鍵確認（要求または応答）、Control planeセッション停止（要求または応答）、およびControl planeセッション終了（要求または応答）のうちの一部または全部は、同一のVENDOR_DEFINED_REQUEST要求メッセージまたは同一のVENDOR_DEFINED_RESPONSE応答メッセージに格納されてもよい。同様に、Data planeセッション開始（要求または応答）、Data planeセッション鍵確認（要求または応答）、およびData planeセッション終了（要求または応答）のうちの一部または全部は、同一のVENDOR_DEFINED_REQUEST要求メッセージまたは同一のVENDOR_DEFINED_RESPONSE応答メッセージに格納されてもよい。
　ところで、Vendor defined SPDMメッセージによるセッション開始要求は、セッション鍵使用開始要求、Even鍵使用開始要求、またはOdd鍵使用開始要求と解釈されてもよい。同様に、Vendor defined SPDMメッセージによるセッション停止要求は、セッション鍵使用停止要求、Even鍵使用停止要求、またはOdd鍵使用停止要求と解釈されてもよい。同様に、Vendor defined SPDMメッセージによるセッション終了要求は、セッション鍵使用終了要求、Even鍵使用終了要求、またはOdd鍵使用終了要求と解釈されてもよい。
　ところで、Control plane hostとControl plane deviceとは、unicast（one-to-one）送信または受信だけではなく、multicast（one-to-many）送信または受信に対応してもよい。つまり、SoCが1つの例を用いて説明したが、SoCは複数設けられていてもよい。また、Data plane hostとData plane deviceとは、unicast（one-to-one）送信または受信だけではなく、multicast（one-to-many）送信または受信に対応してもよい。つまり、SoCが1つの例を用いて説明したが、SoCは複数設けられていてもよい。
　具体的には、例えば、第１SoCが、SPDMリクエスタまたはSPDMレスポンダと、Control plane hostまたはData plane hostとを含む。さらに、第２SoCが、SPDMリクエスタまたはSPDMレスポンダと、Control plane hostまたはData plane hostとを含む。このとき、SensorまたはBridge他端から第１SoCと第２SoCとに同じ情報（例えば、画像系データ、制御系コマンド、制御系データ）が送信されてもよい。
　また、例えば、SensorまたはBridge他端とBridge一端との間はunicastであり、Bridge一端から第１SoCと第２SoCとに対するmulticast（Bridge一端で分岐）であってもよい。また、例えば、SSMCは第１SoCとの間でSPDMセッションを確立してもよい。また、SSMCは第２SoCとの間でSPDMセッションを確立してもよい。また、SSMCは第１SoCと第２SoCとSensorまたはBridge他端とに同じセッション鍵を送信してもよい。
　また、例えば、画像系通信の場合にSSMCは、最初に第１SoCにセッション鍵、Even鍵、またはOdd鍵を送信する。次に、第２SoCに同じセッション鍵、Even鍵、またはOdd鍵を送信する。最後に、SensorまたはBridge他端に同じセッション鍵、Even鍵、またはOdd鍵を送信する。
　また、例えば、制御系通信の場合にSSMCは、最初にSensorまたはBridge他端にセッション鍵、Even鍵、またはOdd鍵を送信する。次に、第２SoCに同じセッション鍵、Even鍵、またはOdd鍵を送信する。最後に、第１SoCに同じセッション鍵、Even鍵、またはOdd鍵を送信する。ただし、SSMCと第１SoCとは別体または一体であってもよいし、SSMCと第２SoCとは別体または一体であってもよい。
　ところで、SSMC、SoC、またはBridge一端は移動体装置に含まれ、SensorまたはBridge他端は撮像装置に含まれてもよい。撮像装置は移動体装置内に内蔵されていてもよいし、撮像装置は移動体装置内に装着されていてもよいし、撮像装置は移動体装置外に装着されていてもよい。このとき、移動体装置内のSSMCと撮像装置内のSensorまたはBridge他端との間の総通信回数または総通信データ量を、移動体装置内のSSMCと移動体装置内のSoCまたはBridge一端との間の総通信回数または総通信データ量よりも少なくすることは、電力効率またはデータ効率の観点でも利点がある。そこで、VENDOR_DEFINED_REQUEST要求メッセージ、VENDOR_DEFINED_RESPONSE応答メッセージ、またはERROR応答メッセージの使用回数または使用データ量が、SSMCとSoCまたはBridge一端との間の制御系通信（例えば、SPDMセッション）よりも、SSMCとSensorまたはBridge他端との間の制御系通信（例えば、SPDMセッション）の方が少なくなるフローチャート例を提案した。
　同様に、SSMCとSoCまたはBridge一端との間のHEARTBEAT周期が、SSMCとSensorまたはBridge他端との間のHEARTBEAT周期よりも短く設定される（ただし、SSMCとSensorまたはBridge他端との間にHEARTBEAT機能を設けなくてもよい）。さらに、特異メッセージが画像系通信（例えば、埋込データ、ブランクな画像データ、拡張パケットヘッダ）または第２制御系通信（例えば、読み出し応答）によってSensorまたはBridge他端からSoCまたはBridge一端に送信される。そして、それに基づいた特異メッセージが第１制御系通信（例えば、HEARTBEAT_ACK応答メッセージ、ERROR応答メッセージ、またはVendor defined SPDMメッセージ）によってSoCまたはBridge一端からSSMCに送信される。このようにした場合にも、上記と同じ利点が得られる。
　この場合、SSMCは、第１制御系通信によって第２制御系通信または画像系通信に関連する異常（例えば、Sensor異常、Bridge異常、SoC異常、通信異常）の有無を把握することができる。なお、上述したVENDOR_DEFINED_RESPONSE応答メッセージの一部または全部には、上述した特異メッセージが格納されていてもよい。また、使用開始タイミング指定はVendor defined SPDMメッセージだけではなく、例えば、HEARTBEAT_ACK応答メッセージまたはERROR応答メッセージによってSoC、Bridge一端、Bridge他端、またはSensorからSSMCに送信されてもよい。
　ところで、第１通信（例えば、第１制御系通信）と第２通信（例えば、第２制御系通信または画像系通信）とを保護する保護部（セキュリティ部）は、第１セキュリティ演算部（例えば、第１制御系通信用）と第２セキュリティ演算部（例えば、第２制御系通信用）と第３セキュリティ演算部（例えば、画像系通信用）とを含んで構成されてもよい。また、第１セキュリティ演算部と第２セキュリティ演算部と第３セキュリティ演算部とは、同じ暗号アルゴリズムが適用されてもよいし、それぞれ異なる暗号アルゴリズムが適用されてもよい。例えば、第１制御系通信向けまたは第２制御系通信向けとして第１セキュリティ演算部または第２セキュリティ演算部にブロック暗号CBCモードまたはブロック暗号CTRモードの何れかとHMAC、CMAC、またはGMACの何れかとの組み合わせが適用されてもよい。また、画像系通信向けとして第３セキュリティ演算部にAES-GCM、AES-GMAC、ブロック暗号CCMモード、HMAC、またはCMACの何れかが適用されてもよい。
　また、第１制御系通信向けまたは第２制御系通信向けとして第１セキュリティ演算部または第２セキュリティ演算部にAES-GCMまたはブロック暗号CCMモードの何れかが適用されてもよい。また、画像系通信向けとして第３セキュリティ演算部にブロック暗号CBCモードまたはブロック暗号CTRモードの何れかとHMAC、CMAC、またはGMACの何れかとの組み合わせが適用されてもよい。ただし、第１セキュリティ演算部と第２セキュリティ演算部とは、別体ではなく一体であってもよい。拡張モード対応CSI-2送信回路および／またはセキュリティ部を保護部として解釈してもよいし、拡張モード対応CSI-2受信回路および／またはセキュリティ部を保護部として解釈してもよい。
　ブロック図やフローチャートなどの何れかの図面を構成する要素のタイミングまたは位置は一例であり、異なるように構成されてもよい。各例で説明した実施の形態は、種々の変形例が存在する。即ち、説明した各例の構成要素は、一部が省略されてもよく、一部または全部が変化していてもよく、一部または全部が変更されていてもよい。また、一部が他の構成要素で置き換えられていてもよく、一部または全部に他の構成要素が追加されていてもよい。更には、構成要素の一部または全部が複数に分割されていてもよい。一部または全部が複数に分離されていてもよい。分割または分離された複数の構成要素の少なくとも一部で機能や特徴を異ならせていてもよい。更に、各構成要素の少なくとも一部を移動させて異なる実施の形態としてもよい。更にまた、各構成要素の少なくとも一部の組み合わせに結合要素や中継要素を加えて異なる実施の形態としてもよい。加えて、各構成要素の少なくとも一部の組み合わせに切り替え機能を加えて異なる実施の形態としてもよい。
　本実施の形態は、説明した各例で示した構成に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。なお、本明細書に記載された効果はあくまでも例示であって限定されるものではなく、また他の効果があってもよい。本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
　さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に説明した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
　また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。また、例えば、説明したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。また、例えば、フローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
　なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が説明した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
　なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、説明した任意の本技術の一部または全部を、説明していない他の技術と併用して実施することもできる。
[変形例Ｉ]
　図２４３は、上記実施の形態およびその変形例におけるライトデータ（WRITE DATA;書き込みデータ）のパケット構成の一例を示したものである。図２４４は、上記実施の形態およびその変形例におけるライトデータの処理の一例を表したものである。なお、図２４３、図２４４において破線で示した箇所は、オプションである。
　以下では、Individualモードのうち、１メッセージ（または１トランザクション）ごとにMAC値を演算するモードを第１CCIモードと称する。Runningモードのうち、所定期間内（例えば、１フレーム内）に送信または受信される１以上のメッセージごとに（例えば、１フレームごとに）MAC値を演算するモードを第２CCIモードと称する。Individualモードのうち、複数メッセージごとにMAC値を演算するモードを第３CCIモードと称する。図２４３には、１メッセージ毎にMAC値を演算するIndividualモード（第１CCIモード）の書き込み命令の一例が示されている。図２４４には、Master側（例えば、アプリケーションプロセッサ（SoC））およびSlave側（例えば、イメージセンサ）において実行される、図２４３の書き込み命令に対する処理の一例が示されている。以下では、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａが、少なくとも２種類のメッセージ認証（MAC）ポリシーのうちいずれか１つを、制御系通信または画像系通信におけるメッセージ認証ポリシーとして選択することができるようになっている。
　例えば、書き込みデータ、読み出しデータ、または復号結果の実行または反映が、常時（No rejection）とMAC検証に成功した場合のみ（Only when MAC matched）との２種類のうちいずれか１つとなっている。例えば、MACと暗号化（復号）との関係が、Encrypt-then-MACとMAC-then-EncryptとEncrypt-and-MACの３種類のうちいずれか１つとなっている。例えば、Encrypt-then-MACが、第１Encrypt-then-MAC（Encrypt-then-MAC-0）と第２Encrypt-then-MAC（Encrypt-then-MAC-1）との２種類のうちいずれか１つとなっている。例えば、MAC対象が、部分的にメッセージ認証の対象から除外するか否かの２種類のうちいずれか１つとなっている。例えば、MAC除外モードの種類が、２種類以上のMAC除外モードのうちいずれか１つとなっている。例えば、MAC無効化に関連する情報が、メッセージ認証、またはメッセージ認証を含むセキュリティ機能の無効化を許容するか否かのうちいずれか１つとなっている。
　S（START condition）からP（STOP condition）までを１メッセージ（または１トランザクション）と定義する。Sequential Write（図２４３）またはSingle Write（WRITE DATA 0のみ書き込み）によって書き込まれる書き込みデータ（WRITE DATA）を１データ群（1 data group）と定義する。図２４３では、１メッセージ内に複数のデータ群が含まれる。上記実施の形態およびその変形例において、ブリッジ他端３１２０ｂまたはセンサ部３１２０ａは、制御系通信において、書き込みデータの一部または全部がメッセージ認証（MAC）の対象となる場合、データ群の数に制約を設けることができるようになっていることが望ましい。
　通常、メッセージ認証がOK（Master側とSlave側とでMAC値が一致、つまり受信したMAC値と受信した１以上のメッセージの一部または全部から演算されたMAC値とが一致）になってから書き込みデータが実行されることが望ましい。そのようにした場合、メッセージ認証がOKになるまでの間、書き込みデータの一部または全部がバッファメモリなどの記憶部に保持される必要がある。しかし、バッファメモリには保持できるデータ量の上限があるため、データ群に制約が無い場合には、その上限を超えてバッファオーバフローが生じ得る。そのため、データ群の数に制約が設けられることが望ましい。
　このような制約を設けるための具体的な方法としては、例えば、Slave側（例えば、イメージセンサ）が、書き込みデータ向けにSlave側（例えば、イメージセンサ）が記憶部（例えば、バッファメモリ）に保持できるMAC対象データ群の上限数（以降では、「上限数Nw_max」と称する）を、Master側（例えば、アプリケーションプロセッサ（SoC））に事前通知しておくことが考えられる。また、他には、例えば、Slave側が、書き込みデータ向けにSlave側が記憶部に保持できるMAC対象データ群のデータ量（例えば、バイト数、ビット数）の上限値（以降では、「上限量Bw_max」と称する）を、Master側に事前通知しておくことが考えられる。
　この事前通知は、事前合意（Private contract）によって代用されてもよい。しかし、例えば、上限数Nw_maxまたは上限量Bw_maxが、機能レジスタを介した通信（例えば、SPDMセッション、Control Planeセッション）によってSlave側（例えば、イメージセンサ）からMaster側（例えば、SoC）に通知されてもよい。ここで、機能レジスタは、機能情報が格納されるレジスタであって、Capability registerとも称され、記憶部の一部または全部である。上限数Nw_maxまたは上限量Bw_maxが、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）によって、機能レジスタを介してSSMCに通知（例えば、読み出し）され、SSMCからMaster側に通知（例えば、書き込み）されてもよい。図２４４に記載のImplicit data（Not transmitted）は省略されてもよい。MCとMACとの間、MACとCRCとの間、MCの後、MACの後、CRCの後、の何れかにCBCモードで用いられる初期化ベクトルIVが格納されてもよい。
　なお、CCIのMaster側をController側と、CCIのSlave側をTarget側と、それぞれ称してもよい。SLAVE ADDRESSをTARGET ADDRESSと称してもよいし、REG ADDRESSをSUB ADDRESSと称してもよい。
　図２４５に示したMax_Aggregation_Extent_Data_Groupsは、上限数Nw_maxを示す機能レジスタの一例である。図２４６に示したMax_Aggregation_Extent_Bufferは、上限量Bw_maxを示す機能レジスタの一例である。上限数Nw_maxまたは上限量Bw_maxは、第１CCIモードまたは第３CCIモード（Individualモード）と第２CCIモード（Runningモード）とで一体であってもよいが、別体であってもよい。第２CCIモードには上限数Nw_maxおよび上限量Bw_maxを設けないようにしてもよい。別体である場合、Runningモードはメッセージ認証の検証を待たずに書き込みデータを実行してもよいため（上限数Nw_maxまたは上限量Bw_maxを厳しく制限する必要がないため）、異なる上限数Nw_maxまたは上限量Bw_maxに設定されることが望ましい。
　図２４７は、上記実施の形態およびその変形例におけるリードデータ（READ DATA；読み出しデータ）のパケット構成の一例を示す図である。図２４８は、上記実施の形態およびその変形例におけるリードデータの処理の一例を表したものである。図２４７には、１メッセージ毎にMAC値を演算するIndividualモード（第１CCIモード）の読み出し命令および読み出し応答の一例が示されている。図２４８には、Master側（例えば、アプリケーションプロセッサ（SoC））およびSlave側（例えば、イメージセンサ）において実行される、図２４７の読み出し命令および読み出し応答に対する処理の一例が示されている。なお、図２４７、図２４８において破線で示した箇所は、オプションである。
　S（START condition）からP（STOP condition）までを１メッセージ（または1トランザクション）と定義する。Sequential Read（図２４７）またはSingle Read（READ DATA 0のみ読み出し）によって読み出される読み出しデータ（READ DATA）を１データ群と定義する。図２４７では、１メッセージ内に、複数のデータ群が含まれる。上記実施の形態およびその変形例において、読み出しデータの一部または全部がメッセージ認証（MAC）の対象となる場合、データ群の数に制約が設けられることが望ましい。
　通常、メッセージ認証がOK（Master側とSlave側とでMAC値が一致、つまり受信したMAC値と受信した１以上のメッセージの一部または全部から演算されたMAC値とが一致）になってから読み出しデータが実行されることが望ましい。そのようにした場合には、読み出しデータの一部または全部がバッファメモリなどの記憶部に保持される必要がある。しかし、バッファメモリには保持できるデータ量の上限があるため、データ群に制約が無い場合には、その上限を超えてバッファオーバフローが生じ得る。そのため、データ群の数に制約が設けられることが望ましい。例えば、帯域内割込みによって読み出し命令を省略して読み出し応答を送信または受信する場合などには、データ群の数に制約が設けられることが望ましい。
　このような制約を設けるための具体的な方法としては、例えば、Master側（例えば、SoC）が、読み出しデータ向けにMaster側（例えば、SoC）が記憶部（例えば、バッファメモリ）に保持できるMAC対象データ群の上限数（以降では、「上限数Nr_max」と称する）を、Slave側（例えば、イメージセンサ）に事前通知しておくことが考えられる。また、他には、例えば、Master側（例えば、SoC）が、読み出しデータ向けにMaster側（例えば、SoC）が記憶部に保持できるMAC対象データ群のデータ量（例えば、バイト数、ビット数）の上限値（以降では、「上限量Br_max」と称する）を、Slave側（例えば、イメージセンサ）に事前通知しておくことが考えられる。
　この事前通知は、事前合意（Private contract）によって代用されてもよい。しかし、例えば、上限数Nr_maxまたは上限量Br_maxが、機能レジスタを介した通信（例えば、SPDMセッション、Control Planeセッション）によってMaster側（例えば、SoC）からSlave側（例えば、イメージセンサ）に通知されてもよい。ここで、機能レジスタは、機能情報が格納されるレジスタであって、Capability registerとも称され、記憶部の一部または全部である。上限数Nr_maxまたは上限量Br_maxが、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）によって、機能レジスタを介してSSMCに通知（例えば、読み出し）され、SSMCからSlave側に通知（例えば、書き込み）されてもよい。SoCとSSMCとが同一または一体である場合、機能レジスタを省略し、上限数Nr_maxまたは上限量Br_maxが、書き込みレジスタを介した通信（例えば、SPDMセッション、Control Planeセッション）によってMaster側（例えば、SoC）からSlave側（例えば、イメージセンサ）に通知（例えば、書き込みレジスタに書き込み）されてもよい。図２４８に記載のImplicit data（Not transmitted）は省略されてもよい。MCとMACとの間、MACとCRCとの間、MCの後、MACの後、CRCの後、の何れかにCBCモードで用いられる初期化ベクトルIVが格納されてもよい。図２４４、図２４８、および図２５０では、Clear texts covered by MACであるImplicit data（MC c-1 [7:0]乃至MC 1 [7:0]）がREG ADDRESS [7:0]とMC 0 [7:0]との間に挿入される例を用いて説明したが、Clear texts covered by MACであるImplicit dataは他位置に挿入されてもよいし、例えばMC 0 [7:0]の後に挿入されてもよい。また、MC c-1 [7:0]乃至MC 1 [7:0]の順番は、MC 1 [7:0]乃至MC c-1 [7:0]であってもよい。他図も含めて、明示的なMC（Implicit dataではないMC）は2バイト以上であってもよいし、明示的なMCはMC 0 [7:0]だけでなくMC 1 [7:0]またはMC [15:8]も含んでもよいし、CRCの一部または全部は省略されてもよい。
　図２４５に示したMax_Aggregation_Extent_Data_Groupsは、上限数Nr_maxを示す機能レジスタまたは書き込みレジスタの一例である。Master側が記憶部に保持できるMAC対象データ群の上限数は、読み出しデータ向けにMaster側が記憶部に保持できるMAC対象データ群のデータ量（例えば、バイト数、ビット数）上限であってもよい。図２４６に示したMax_Aggregation_Extent_Bufferは、上限量Br_maxを示す機能レジスタまたは書き込みレジスタの一例である。図２４５中または図２４６中の一部または全部の表現は、Master側とSlave側とでそれぞれ適切な数値範囲を定義するためや、Master側とSlave側とでFieldが重複しないようにするためなどによって、Master側とSlave側とで異ならせてもよい。上限数Nr_maxまたは上限量Br_maxは、第１CCIモードまたは第３CCIモード（Individualモード）と第２CCIモード（Runningモード）とで一体であってもよいが、別体であってもよい。第２CCIモードには上限数Nr_maxおよび上限量Br_maxを設けないようにしてもよい。別体である場合、Runningモードはメッセージ認証の検証を待たずに読み出しデータを実行してもよいため（上限数Nr_maxまたは上限量Br_maxを厳しく制限する必要がないため）、異なる上限数Nr_maxまたは上限量Br_maxに設定されることが望ましい。
　Slave側またはMaster側が記憶部に保持できるMAC対象データ群の上限数またはデータ量上限は、書き込みデータと読み出しデータとで一体であってもよいが、別体であってもよい。別体である場合、書き込みデータと読み出しデータとで、異なる上限数またはデータ量上限に設定されることが可能になる。以上のように、機能レジスタは、制御系通信または画像系通信のメッセージ認証に対してCCIのMaster側またはSlave側の保護部が記憶部に保持できるデータ量上限に関連する情報（例えば、MAC対象データ群の上限数、MAC対象データ群のデータ量上限）が格納される。以上のように、機能レジスタには、制御系通信または画像系通信のメッセージ認証に対してCCIのMaster側またはSlave側の保護部が記憶部に保持できるデータ量上限に関連する情報（例えば、上限数Nw_max、上限数Nr_max、上限量Bw_max、上限量Br_max）が格納される。Slave側またはMaster側が記憶部に保持できるMAC対象データ群の上限数またはデータ量上限を超えない範囲内のMAC対象データ群に対してメッセージ認証が検証される。
　なお、次のメッセージ認証が開始される前までに、バッファ（例えば、CCI受信バッファ）処理は完了されることが望ましい。CCIのMaster側からの読み出し命令に応じて、バッファ処理が終わったか否かを示す情報（読み出し応答）がCCIのSlave側からMaster側に送信されてもよい。CCIのMaster側からの書き込み命令として、バッファ処理が終わったか否かを示す情報がCCIのMaster側からSlave側に送信されてもよい。バッファ処理を完了させるための待機時間または禁則時間などの情報が、例えば、事前合意、機能レジスタ、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。CCIのSlave側は、バッファ処理が完了したことを示す情報を画像系通信の埋め込みデータに格納し、CCIのSlave側からMaster側に送信してもよい。CCIのMaster側は、これらの何れかの情報に基づいて、CCIのSlave側におけるバッファ処理が完了されたか否かを判断してもよい。同様に、CCIのSlave側は、これらの何れかの情報に基づいて、CCIのMaster側におけるバッファ処理が完了されたか否かを判断してもよい。
　図２４３、図２４７では、S(START condition)、Sr(REPEATED START condition)、P(STOP condition)、A(Acknowledge(ACK))、およびA-(Negative acknowledge(NACK)がメッセージ認証対象外となっていた。しかし、他の例も含めて、S(START condition)、Sr(REPEATED START condition)、P(STOP condition)、A(Acknowledge(ACK))、A-(Negative acknowledge(NACK)、またはこれらに相当する情報がメッセージ認証対象となっていてもよい。Capability register example、Vendor defined SPDM message example、またはEXTENDED HEADER exampleの説明において、「Bits」はSize in bitsであり、BitsのOffsetは省略してあるが、実際にはOffsetが設けられてもよい。「Field」、「Bits」、または「Value : Description」の表現は一例である。「Field」は「Name」を少なくとも含む表現で称されてもよく、「Value : Description」は「Value」または「Description」を少なくとも含む表現で称されてもよい。
　図２４９は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２５０は、上記実施の形態およびその変形例におけるライトデータの処理の一例を表したものである。図２４９には、複数メッセージ毎にMAC値を演算するIndividualモード（第３CCIモード）の書き込み命令の一例が示されている。図２５０には、図２４９の書き込み命令に対する処理の一例が示されている。読み出し命令および読み出し応答の一例については、上述の説明から自明のため、省略する。なお、図２４９、図２５０において破線で示した箇所は、オプションである。
　図２４９には、１メッセージ内に１つのデータ群が送信される場合が例示されている。なお、１メッセージ内に複数のデータ群が送信されてもよい。第３CCIモードでは、EXTENDED HEADERが、例えば、図２５１に示したように、そのEXTENDED HEADERを含むメッセージに“MAC値を含むREPEATED START condition行”または“MAC値”が格納されるか否かを示す情報（例えば、ビットフラグ）を含んでもよい。EXTENDED HEADERを含むSTART condition行またはEXTENDED HEADERは省略されてもよい。
　図２５２は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２５２には、複数メッセージ毎にMAC値を演算するIndividualモード（第３CCIモード）の書き込み命令の一例が示されている。書き込み応答、読み出し命令および読み出し応答の一例については、上述の説明から自明のため、省略する。
　EXTENDED HEADERが無い場合には、周期的（例えば、２つのメッセージ毎）にMAC値を含むREPEATED START condition行またはMAC値を送信または受信してもよい。一方、EXTENDED HEADERが有る場合には、変則的（EXTENDED HEADERが無い場合の周期よりも少ない数のメッセージ後（例えば１つのメッセージ後）に）にMAC値を含むREPEATED START condition行またはMAC値を送信または受信してもよい。
　MAC送信周期（例えば、２つのメッセージ毎）を、事前合意、機能レジスタ、またはSPDMメッセージ（例えば、Vendor defined SPDMメッセージ）などを介してCCIのMaster側とSlave側とで認識合わせすることによって、この様にEXTENDED HEADERを省略してもよい。つまり、MAC値を含むREPEATED START condition行またはMAC値の周期的な送信が可能な場合には、EXTENDED HEADERが不要である。MAC値を含むREPEATED START condition行またはMAC値の周期的な送信が不可能な場合には、EXTENDED HEADERを活用してもよい。
　データの送信効率または受信効率を向上（EXTENDED HEADERによるオーバーヘッドを最小化）させるために、MAC値を含むREPEATED START condition行またはMAC値の周期的な送信が不可能な場合にのみ、EXTENDED HEADERが送信または受信されてもよい。例えば、EXTENDED HEADERは、MAC値を含むREPEATED START condition行またはMAC値を周期的に送信または受信するか否か、MAC値を含むREPEATED START condition行またはMAC値を変則的に送信または受信するか否か、現在のメッセージ内にMAC値を含むREPEATED START condition行またはMAC値が含まれるか否か、次のメッセージ内にMAC値を含むREPEATED START condition行またはMAC値が含まれるか否か、などの情報（例えば、ビットフラグ）が格納されてもよい。
　例えば、複数Nのメッセージ毎にMACが送信される場合、EXTENDED HEADERには、例えば、図２５３に示したように、Nが固定なのか可変なのかを示す情報が格納されてもよい。例えば、Nの最大値N_Maxを、事前合意、機能レジスタ、またはSPDMメッセージ（例えば、Vendor defined SPDMメッセージ）などを介してCCIのMaster側とSlave側とで認識合わせし、Nが固定な場合はN=N_MaxとしてMACが送信され、Nが可変な場合はN≦N_MaxとしてMACが送信されてもよい。また、Nが可変な場合はEXTENDED HEADERが送信されるようにしてもよい。
　図２５４は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２５５は、上記実施の形態およびその変形例におけるライトデータの処理の一例を表したものである。図２５４には、複数メッセージ毎にMAC値を演算するRunningモード（第２CCIモード）の書き込み命令の一例が示されている。図２５５には、図２５４の書き込み命令に対する処理の一例が示されている。読み出し命令および読み出し応答の一例については、上述の説明から自明のため、省略する。なお、図２５４、図２５５において破線で示した箇所は、オプションである。
　図２５４には、１メッセージ内に１つのデータ群が送信される場合が例示されている。なお、１メッセージ内に複数のデータ群が送信されてもよい。第２CCIモードでは、EXTENDED HEADERが、そのEXTENDED HEADERを含むメッセージの受信完了後にMAC演算またはCRC演算を完了できるか（そのEXTENDED HEADERを含むメッセージが最後のMAC対象メッセージまたはCRC対象メッセージか）否かを示す情報（例えば、ビットフラグ）を含んでもよい。EXTENDED HEADERを含むSTART condition行またはEXTENDED HEADERは、省略されてもよい。
　データの送信効率または受信効率を向上させるために、メッセージ群における最終メッセージである場合のみ、EXTENDED HEADERが送信または受信されるように構成されてもよい。第２CCIモードでは、所定期間内（例えば、１フレーム内）に送信されるメッセージ群における最終メッセージ（WRITE DATA 0～WRITE DATA ?-1）が、そのメッセージの受信完了後にMAC演算またはCRC演算を完了できるか（そのメッセージが最後のMAC対象メッセージまたはCRC対象メッセージか）否かを示す情報（例えば、ビットフラグ）を含んでもよい。TRIGGER DESCRIPTOR（ESS CCI Service Descriptorの一部または全部を含む表現で称されてもよい）が設けられてもよい。この場合には、第２CCIモードでは、所定期間内（例えば、１フレーム内）に送信されるメッセージ群における最終メッセージ（TRIGGER DESCRIPTOR）が、そのメッセージの受信完了後にMAC演算またはCRC演算を完了できるか（そのメッセージが最後のMAC対象メッセージまたはCRC対象メッセージか）否かを示す情報（例えば、ビットフラグ）を含んでもよい。
　例えば、少なくともRunningモード（第２CCIモード）の操作に関するWRITEレジスタアドレス（REG ADDRESS）を定義し、そのWRITEレジスタアドレスの書き込みデータ（WRITE DATA 0～WRITE DATA ?-1またはTRIGGER DESCRIPTOR）または指定（この場合、書き込みデータは省略されてもよい）に応じて、Slave側はRunningモードの操作（例えば、MAC演算またはCRC演算の完了可否、復号処理を開始可否）を判断してもよい。同様に、少なくともRunningモード（第２CCIモード）の操作に関するREADレジスタアドレス（REG ADDRESS）を定義し、そのREADレジスタアドレスの読み出しデータ（READ DATA 0～READ DATA ?-1またはTRIGGER DESCRIPTOR）または指定（この場合、読み出しデータは省略されてもよい）に応じて、Master側はRunningモードの操作（例えば、MAC演算またはCRC演算の完了可否、復号処理を開始可否）を判断してもよい。これらによってCCIのMaster側またはSlave側は、MACまたはCRCの演算完了タイミングを、CCI通信相手に指定することが可能になる。
　図２５６は、第２CCIモードにおけるMACまたはCRCの演算処理の一例を説明するフローチャートである。図２５６には、センサ部３１２０ａまたはブリッジ他端３１２０ｂにおける処理が例示されている。なお、図２５６において破線で示した処理は、オプションである。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、ループ処理を終了するか否か判定する（ステップＳ４１０１）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４１０１；Ｙ）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４１０１；Ｎ）、MAC値の演算（MAC演算）またはCRC値の演算（CRC演算）を開始するか否か判定する（ステップＳ４１０２）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、自身に対応するSLAVE ADDRESSのメッセージ受信を開始した場合に、MAC値の演算（MAC演算）またはCRC値の演算（CRC演算）を開始する（ステップＳ４１０２；Ｙ、ステップＳ４１０３）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、自身に対応するSLAVE ADDRESSのメッセージを受信しない場合に、上記演算を開始せず（ステップＳ４１０２；Ｎ）、ステップＳ４１０１に戻る。第２CCIモードは、所定期間内または所定ビット幅内に送信された書き込み命令、読み出し命令および読み出し応答（つまり、CCIコマンド）の一部もしくは全部をメッセージ認証またはCRCの保護対象とするモードである。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、第２CCIモードでは、例えば、MAC値またはCRC値を、同じフレームまたは次フレームの高速データ送信の埋め込みデータ、または、次CCIコマンドのデータに格納して、通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂに送信または通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂから受信してもよい。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、演算完了できることを示す情報を受信したか否か判定する（ステップＳ４１０４）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、演算完了できることを示す情報を受信した場合（ステップＳ４１０４；Ｙ）、第１所定期間T1または第１所定ビット幅W1が経過した場合（ステップＳ４１０７；Ｙ）、第２所定期間T2または第２所定ビット幅W2が経過した場合（ステップＳ４１０６；Ｙ）、メッセージ受信が完了していなければ、メッセージ受信の完了まで待機することが望ましい（ステップＳ４１０８）。なお、この待機を省略してもよい。
　ここで、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、今回が初回演算である場合（ステップＳ４１０５；Ｙ）、第１所定期間T1または第１所定ビット幅W1が経過したか否か判定する（ステップＳ４１０７）。また、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、今回が初回演算ではない場合（ステップＳ４１０５；Ｎ）、第２所定期間T2または第２所定ビット幅W2が経過したか否か判定する（ステップＳ４１０６）。
　MAC値またはCRC値が埋め込みデータに格納される場合、埋込データ（埋め込みデータ）はフレームレートに応じて周期的に送信される。そのため、「第２所定期間T2または第２所定ビット幅W2に相当する時間＜フレーム送信周期」であることが望ましい。「第２所定期間T2または第２所定ビット幅W2に相当する時間＋メッセージの受信に必要な時間＋遅延時間など＜フレーム送信周期」であることがさらに望ましい。第１所定期間T1と第２所定期間T2とが互いに同一であってもよいが、互いに異なっていてもよい。第１所定期間T1と第２所定期間T2とが互いに異なる場合にはシステム設計の自由度が向上する。第１所定ビット幅W1と第２所定ビット幅W2とが、互いに同一であってもよいが、互いに異なっていてもよい。第１所定ビット幅W1と第２所定ビット幅W2とが互いに異なる場合にはシステム設計の自由度が向上する。フレーム送信を開始する前の設定（例えば、レジスタ設定）などのためにフレーム送信周期よりも時間を要する場合、「第１所定期間T1＞第２所定期間T2」または「第１所定ビット幅W1＞第２所定ビット幅W2」とすればよい。
　メッセージ群における最終メッセージまたはEXTENDED HEADERがMAC演算またはCRC演算を完了できるか否かを示す情報を含む場合、その情報は、MACを送信するか否か、CRCを送信するか否か、MACおよびCRCを送信するか否か、などであってもよい（図２５７）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、メッセージ群における最終メッセージがこれらの何れかの情報を含む場合、つまりレジスタ定義（Register definition）に対応するレジスタアドレス（REG ADDRESS）の受信に応じた、そのレジスタアドレスに対応して受信される書き込みデータに基づいて、MAC演算またはCRC演算を完了できるか否かを判断できる（ステップＳ４１０９）。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、拡張パケットヘッダ（EXTENDED HEADER）がこれらの何れかの情報を含む場合、つまりTRIGGER DESCRIPTORまたは拡張パケットヘッダに対応するレジスタアドレス（REG ADDRESS）の受信に応じた、そのレジスタアドレスに対応して受信される書き込みデータに基づいて、MAC演算またはCRC演算を完了できるか否かを判断できる（ステップＳ４１０９）。
　なお、他表による例示も含めて、Field、Bits、Value、またはDescriptionの表現は別表現であってもよい。例えば、Fieldは、Transmit_Tag、End_Tag、End_CRC、End_MAC、End_CRC_MACなどと表現されてもよい。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、第２CCIモードでCRC値の演算とその送信または受信とを実行しつつ、第１CCIモードまたは第３CCIモードでMAC値または暗号文（暗号化または復号）の演算とその送信または受信とを実行してもよい（ステップＳ４１１０）。この場合、第１CCIモードまたは第３CCIモードで送信または受信される１以上のメッセージの一部または全部を、第２CCIモードでCRC値を演算する対象（CRC対象）とすればよい。この場合、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、第１CCIモードまたは第３CCIモードでCRC値を演算しなくてもよく、制御系通信を介してCRC値を送信または受信しなくてもよいため、制御系通信のオーバーヘッドを小さくできる。この場合、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、第２CCIモードでMAC値または暗号文（暗号化または復号）の演算とその送信または受信とを実行する必要はないが、第２CCIモードでもMAC値または暗号文（暗号化または復号）の演算とその送信または受信とを実行するようにしてもよい。このような複合モード（Dual mode）を選択するか否かは、例えば、事前合意、機能レジスタ（図２５７）、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。つまり、図２５７をCapability register example（機能レジスタ例）としてもよい。
　図２５８は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２５９は、上記実施の形態およびその変形例におけるライトデータの処理の一例を表したものである。図２５８には、複数メッセージ毎にMAC値を演算するRunningモード（第２CCIモード）の書き込み命令の一例が示されている。図２５９には、図２５８の書き込み命令に対する処理の一例が示されている。読み出し命令および読み出し応答の一例については、上述の説明から自明のため、省略する。なお、図２５８、図２５９において破線で示した箇所は、オプションである。
　AEADアルゴリズムであるGCMまたはCCMでは、書き込みデータまたは読み出しデータの一部または全部が暗号化される場合、CCI通信相手から受信したデータ列（メッセージ列）の順序のままでは復号（暗号化）およびMAC検証のAEAD処理を実行できない。これはGCMまたはCCMには、「Clear texts covered by MAC」→「Encrypted data covered by MAC」→「MAC」の順序で処理を実行しなければならないという制約があるためである。そのため、CCI伝送のデータ列が図２５８の順序である場合、CCIのMaster側およびSlave側は図２５９の順序（つまり、送信するまたは受信したデータ群とは異なるデータ順序）で内部処理を実行する必要がある。第２CCIモードでは、EXTENDED HEADERが、そのEXTENDED HEADERを含むメッセージから復号処理を開始できるか（そのEXTENDED HEADERを含むメッセージに応じて復号処理を開始できるか）否かを示す情報（例えば、ビットフラグ）を含んでもよい。EXTENDED HEADERを含むSTART condition行またはEXTENDED HEADERは、省略されてもよい。第２CCIモードでは、所定期間内（例えば、１フレーム内）に送信されるメッセージ群における最終メッセージ（WRITE DATA 0～WRITE DATA ?-1）またはTRIGGER DESCRIPTORを設ける場合にはTRIGGER DESCRIPTOR（最終メッセージ）が、そのメッセージから復号処理を開始できるか（その最終メッセージを含むメッセージに応じて復号処理を開始できるか）否かを示す情報（例えば、ビットフラグ）を含んでもよい。これらによってCCIのMaster側またはSlave側は、GCMまたはCCMにおける復号処理の開始タイミングを、CCI通信相手に指定することが可能になる。
　図２６０は、第２CCIモードにおけるMACまたはCRCの演算処理の一例を説明するフローチャートである。図２６０には、センサ部３１２０ａまたはブリッジ他端３１２０ｂにおける処理が例示されている。なお、図２６０において破線で示した処理は、オプションである。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、ループ処理を終了するか否か判定する（ステップＳ４２０１）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４２０１；Ｙ）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４２０１；Ｎ）、MAC値の演算（MAC演算）を開始するか否か判定する（ステップＳ４２０２）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、自身に対応するSLAVE ADDRESSのメッセージ受信を開始した場合に、MAC値の演算（MAC演算）を開始する（ステップＳ４２０２；Ｙ、ステップＳ４２０３）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、自身に対応するSLAVE ADDRESSのメッセージを受信しない場合に、上記演算を開始せず（ステップＳ４２０２；Ｎ）、ステップＳ４１０１に戻る。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、第２CCIモードでは、例えば、MAC値またはCRC値を、同じフレームまたは次フレームの高速データ送信の埋め込みデータ、または、次CCIコマンドのデータに格納して、通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂに送信または通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂから受信してもよい。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、復号開始できることを示す情報を受信したか否か判定する（ステップＳ４２０４）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、復号開始できることを示す情報を受信した場合（ステップＳ４２０４；Ｙ）、第１所定期間T1または第１所定ビット幅W1が経過した場合（ステップＳ４２０７；Ｙ）または第２所定期間T2または第２所定ビット幅W2が経過した場合（ステップＳ４２０６；Ｙ）には、メッセージ受信が完了していなければ、メッセージ受信の完了まで待機することが望ましい（ステップＳ４２０８）。なお、この待機を省略してもよい。
　ここで、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、今回が初回演算である場合（ステップＳ４２０５；Ｙ）、第１所定期間T1または第１所定ビット幅W1が経過したか否か判定する（ステップＳ４２０７）。また、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、今回が初回演算ではない場合（ステップＳ４２０５；Ｎ）、第２所定期間T2または第２所定ビット幅W2が経過したか否か判定する（ステップＳ４２０６）。
　Master側によって暗号化されたデータ（暗号文）に対するSlave側による内部処理（例えば、復号演算、暗号化演算）の開始、またはSlave側によって暗号化されたデータ（暗号文）に対するMaster側による内部処理の開始を、復号または復号処理の開始と定義する。メッセージ群における最終メッセージまたはEXTENDED HEADERが、復号処理を開始できるか否かを示す情報を含む場合、その情報は、復号処理を開始するか否か、AAD（Additional Authenticated Data）処理を完了するか否か、AD（Associated Data）処理を完了するか否か、などであってもよい（図２６１）。センサ部３１２０ａまたはブリッジ他端３１２０ｂは、メッセージ群における最終メッセージが、これらの何れかの情報を含む場合、レジスタ定義（Register definition）に対応するレジスタアドレス（REG ADDRESS）の受信に応じた、そのレジスタアドレスに対応して受信される書き込みデータに基づいて、復号処理を開始できるか否かを判断してもよい（ステップＳ４２０９）。EXTENDED HEADER exampleをTRIGGER DESCRIPTOR exampleとしてもよいし、TRIGGER DESCRIPTORをEXTENDED HEADERとしてもよいし、EXTENDED HEADERをTRIGGER DESCRIPTORとしてもよいし、図２５７または図２６１はTRIGGER DESCRIPTOR exampleであってもよい。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、拡張パケットヘッダ（EXTENDED HEADER）がこれらの何れかの情報を含む場合、拡張パケットヘッダに対応するレジスタアドレス（REG ADDRESS）の受信に応じた、そのレジスタアドレスに対応して受信される書き込みデータに基づいて、復号処理を開始できるか否かを判断してもよい（ステップＳ４２０９）。
　なお、他表による例示も含めて、Field、Bits、Value、またはDescriptionの表現は別表現であってもよい。例えば、Fieldは、End_AAD、End_AD、などと表現されてもよい。上述したTransmit_CRC、Transmit_MAC、Transmit_CRC_MAC、Transmit_Tag、End_Tag、End_CRC、End_MAC、End_CRC_MACなどのFieldによるMAC演算またはCRC演算を完了できるか否かの判断に応じて、復号処理を開始できるか否かを判断してもよい。
　センサ部３１２０ａまたはブリッジ他端３１２０ｂは、例えば、MAC演算および復号の完了まで待機した後（ステップＳ４２１０）、MAC演算結果を通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂに送信する（ステップＳ４２１１）。その後、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、ステップＳ４２０１を実行する。
　図２６２は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２６３は、上記実施の形態およびその変形例におけるライトデータの処理の一例を表したものである。図２６２には、複数メッセージ毎にMAC値を演算するRunningモード（第２CCIモード）の書き込み命令の一例が示されている。図２６３には、図２６２の書き込み命令に対する処理の一例が示されている。読み出し命令および読み出し応答の一例については、上述の説明から自明のため、省略する。なお、図２６２、図２６３において破線で示した箇所は、オプションである。
　図２６２では、暗号化されたデータ（Encrypted data covered by MAC）の送信開始以降または受信開始以降において、AEAD処理のMAC処理（MAC生成またはMAC検証）が完了するまで、暗号化されたデータ以外を暗号化対象外およびMAC対象外（Clear texts not covered by MAC）となっている。この場合、センサ部３１２０ａまたはブリッジ他端３１２０ｂは、暗号化されたデータの受信に応じて、暗号化されたデータの復号（暗号化）を開始することが可能になる。この場合、2個目のメッセージ以降のEXTENDED HEADERは、改竄に対して無防備な状態になるので、EXTENDED HEADERを含むSTART condition行またはEXTENDED HEADERは、省略されることが望ましい。
　なお、図２６２に記載の構成や、図２６３に記載の処理は、１メッセージごとにMAC値を演算するIndividualモード（第１CCIモード）または複数メッセージごとにMAC値を演算するIndividualモード（第３CCIモード）においても適用可能である。
　図２６４は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２６５は、上記実施の形態およびその変形例におけるライトデータの処理の一例を表したものである。図２６４には、１メッセージごとにMAC値を演算するIndividualモード（第１CCIモード）の書き込み命令の一例が示されている。図２６５には、図２６４の書き込み命令に対する処理の一例が示されている。第１CCIモードの読み出し命令および読み出し応答の一例や、第３CCIモードの書き込み命令、第３CCIモードの読み出し命令および読み出し応答については、上述の説明から自明のため、省略する。なお、図２６４、図２６５において破線で示した箇所は、オプションである。
　第１CCIモードまたは第３CCIモードの書き込み命令または読み出し命令および読み出し応答の場合、CCIのSlave側は、メッセージカウンタ値、MAC値、または初期化ベクトルが格納されるレジスタアドレスの受信完了に応じて復号（暗号化）を開始できる。なお、メッセージカウンタ値は、メッセージカウンタの値またはメッセージカウント値と同義である。CCIのSlave側は、メッセージカウンタ値、MAC値、または初期化ベクトルの受信開始、受信完了、または検証成功（Master側とSlave側とで値が一致、つまり受信側の値と受信した送信側の値とが一致）に応じて復号（暗号化）を開始できる。アルゴリズムがGCMまたはCCMの場合、かつメッセージカウンタMC0が初期化ベクトルに含まれる場合、メッセージカウンタMC0が改竄されるとMAC値が変化する。そのため、メッセージカウンタ値をClear texts covered by MACとする必要はない。外部伝送の効率または内部処理の効率などを考慮する場合、メッセージカウンタ値をメッセージ認証の対象外とすることが望ましい。ただし、実装の共通化またはアルゴリズムの切り替えなどを考慮する場合、メッセージカウンタ値をClear texts covered by MACとし、メッセージカウンタ値をメッセージ認証の対象とすることが望ましい。メッセージカウンタ値をメッセージ認証の対象とするか否かを切り替え（選択）できるようにしてもよい。メッセージカウンタ値をメッセージ認証の対象とするか否かは、例えば、事前合意、機能レジスタ、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。
　図２６６は、第１CCIモードにおけるMACおよびCRCの演算処理の一例を説明するフローチャートである。図２６６には、センサ部３１２０ａ、ブリッジ他端３１２０ｂ、通信制御部３１１０ａ、ブリッジ一端３１１０ｂ、通信制御部３１１０ｃまたはディスプレイ（以降では、「所定のデバイス」と称する）における処理が例示されている。なお、図２６６において破線で示した処理は、オプションである。
　所定のデバイスは、ループ処理を終了するか否か判定する（ステップＳ４３０１）。所定のデバイスは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４３０１；Ｙ）。所定のデバイスは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４３０１；Ｎ）、MAC値の演算（MAC演算）を開始するか否か判定する（ステップＳ４３０２）。所定のデバイスは、例えば、自身に対応するSLAVE ADDRESSのメッセージ受信を開始した場合に、MAC値の演算（MAC演算）を開始する（ステップＳ４３０２；Ｙ、ステップＳ４３０３）。所定のデバイスは、例えば、自身に対応するSLAVE ADDRESSのメッセージを受信しない場合に、上記演算を開始せず（ステップＳ４３０２；Ｎ）、ステップＳ４３０１を実行する。
　所定のデバイスは、メッセージカウンタ値を受信開始したか否か判定する（ステップＳ４３０４）。所定のデバイスは、メッセージカウンタ値を受信開始しない場合（ステップＳ４３０４；Ｎ）、ステップＳ４３０４を繰り返し実行する。所定のデバイスは、メッセージカウンタ値を受信開始した場合（ステップＳ４３０４；Ｙ）、MAC値を受信開始したか否か判定する（ステップＳ４３０５）。
　所定のデバイスは、MAC値を受信開始しない場合（ステップＳ４３０５；Ｎ）、ステップＳ４３０５を繰り返し実行する。所定のデバイスは、MAC値を受信開始した場合（ステップＳ４３０５；Ｙ）、メッセージカウンタ値の検証に成功したか否か判定する（ステップＳ４３０６）。所定のデバイスは、メッセージカウンタ値の検証に成功しなかった場合（ステップＳ４３０６；Ｎ）、MAC演算を終了する（ステップＳ４３０７）。所定のデバイスは、メッセージカウンタ値の検証に成功した場合（ステップＳ４３０６；Ｙ）、復号を開始する（ステップＳ４３０８）。ステップＳ４３０５とステップＳ４３０６とは順番が逆でもよい。ステップＳ４３０４またはステップＳ４３０５は、所定の時間が経過しても受信開始しない場合、MAC演算を終了する（ステップＳ４３０７）に進んでもよい。
　所定のデバイスは、CRC値を受信し、CRC検証に成功したか否か判定する（ステップＳ４３０９）。所定のデバイスは、所定の時間が経過してもCRC値を受信しない、または、CRC検証に成功しなかった場合（ステップＳ４３０９；Ｎ）、MAC演算を終了する（ステップＳ４３０７）。所定のデバイスは、CRC値を受信し、CRC検証に成功した場合（ステップＳ４３０９；Ｙ）、MAC演算および復号の完了まで待機する（ステップＳ４３１０）。
　続いて、所定のデバイスは、MAC検証に成功したか否かを判定する（ステップＳ４３１１）。所定のデバイスは、MAC検証に成功しなかった場合（ステップＳ４３１１；Ｎ）、または、MAC演算を終了した場合（ステップＳ４３０７）、復号結果を破棄する（ステップＳ４３１２）。所定のデバイスは、MAC検証に成功した場合（ステップＳ４３１１；Ｙ）、復号結果を実行する（ステップＳ４３１３）。
　所定のデバイスは、復号結果を破棄した場合（ステップＳ４３１２）、または、復号結果を実行した場合（ステップＳ４３１３）、メッセージを破棄する（ステップＳ４３１４）。その後、所定のデバイスは、メッセージカウンタ値検証、CRC検証、MAC検証の成否を通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂに送信し（ステップＳ４３１５）、ステップＳ４３０１を実行する。
　ところで、書き込みデータまたは読み出しデータが暗号化されている場合、書き込みデータまたは読み出しデータの復号結果の実行または反映は、常時（Always、No rejection）であってもよいし、メッセージ認証に成功、つまりMAC検証に成功した場合のみ（Only when MAC matched）であってもよい。一方、書き込みデータまたは読み出しデータが暗号化されていない場合、書き込みデータまたは読み出しデータの実行または反映は、常時（Always、No rejection）であってもよいし、メッセージ認証に成功した場合のみ（Only when MAC matched）であってもよい。これらはメッセージ認証ポリシーであって、例えば、事前合意、機能レジスタ（図２６７）、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）（図２６８）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。メッセージ認証ポリシーは、画像系通信のMACモード毎または制御系通信のMACモード毎やCCIモード毎に異なってもよく、それぞれ毎に認識合わせされてもよい。アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の制御系通信向けまたは画像系通信向けメッセージ認証ポリシーは、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）を介してSSMCに送信またはSSMCから送信された情報に基づいて選択されてもよい。アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の保護部は機能レジスタを含み、機能レジスタに格納される情報はSPDMメッセージ（例えば、Vendor defined SPDMメッセージ）などを介してSSMCに送信またはSSMCから送信され、機能レジスタは、保護部が選択可能なメッセージ認証ポリシー候補を示す情報が格納され、保護部が選択可能なメッセージ認証ポリシー候補は、第１メッセージ認証ポリシー（例えば、書き込みデータまたは読み出しデータの実行または反映が常時）と前記第２メッセージ認証ポリシー（例えば、書き込みデータまたは読み出しデータの実行または反映がメッセージ認証に成功した場合のみ）とのうちの少なくとも何れかであり、制御系通信向けまたは画像系通信向けメッセージ認証ポリシーは、保護部が選択可能なメッセージ認証ポリシー候補の中から選択されてもよい。例えばSSMCは、アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の機能レジスタに格納される情報に基づいて、一方（例えば、SSMC、アプリケーションプロセッサ、またはブリッジ一端）の機能レジスタと他方（例えば、イメージセンサ、ディスプレイ、またはブリッジ他端）の機能レジスタとの両方が満たす条件（AND条件）を把握できるので、適切な設定情報をSPDMメッセージ（例えば、Vendor defined SPDMメッセージ）などを介してアプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端に通知できる。
　制御系通信と画像系通信とに関わらず、アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の保護部は、CRC検証をMAC検証よりも先に実行するために、復号処理の対象となる暗号化されたデータを含むデータ群に対してCRC値を演算することが望ましいが、その限りではない。
　図２６９は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２７０は、上記実施の形態およびその変形例におけるライトデータの処理の一例を表したものである。図２６９には、１メッセージごとにMAC値を演算するIndividualモード（第１CCIモード）の書き込み命令の一例が示されている。図２７０には、図２６９の書き込み命令に対する処理の一例が示されている。第１CCIモードの読み出し命令および読み出し応答の一例については、上述の説明から自明のため、省略する。なお、図２６９、図２７０において破線で示した箇所は、オプションである。
　アルゴリズムがGMAC（暗号化しないGCM）の場合、MAC演算のリードタイムを短縮できるので、受信されたExternal transmissionのデータ順序で内部処理（internal processing）することが望ましい。ただし、暗号化しない場合でも暗号化する場合と同じデータ順序で内部処理してもよい。その場合、暗号化の有無に関わらず同じ内部処理にできるので、GCMで暗号化の有無を切り替える場合に特に好適となる。アルゴリズムがGMACの場合、かつメッセージカウンタMC0が初期化ベクトルに含まれる場合、メッセージカウンタMC0が改竄されるとMAC値が変化するので、メッセージカウンタMC0をClear texts covered by MACとする必要はない。ただし、メッセージカウンタMC0をClear texts covered by MACとしてもよく、アルゴリズムとしてGMACが選択された場合とGMAC以外のアルゴリズム（例えば、CMAC、HMAC）が選択された場合とで同じ内部処理（Internal processing）にできる利点がある。
　図２７１は、第１CCIモードにおける内部処理の切り替え処理の一例を説明するフローチャートである。図２７１には、センサ部３１２０ａまたはブリッジ他端３１２０ｂにおける処理が例示されている。なお、図２７１において破線で示した処理は、オプションである。
　所定のデバイスは、ループ処理を終了するか否か判定する（ステップＳ４４０１）。所定のデバイスは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４４０１；Ｙ）。所定のデバイスは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４４０１；Ｎ）、内部処理順序の機能レジスタ情報の読み出し要求または命令を受信したか否か判定する（ステップＳ４４０２）。所定のデバイスは、内部処理順序の機能レジスタ情報の読み出し要求または命令を受信した場合には、機能レジスタ情報を通信制御部３１１０ａ，３１１０ｃ，またはブリッジ一端３１１０ｂに送信する（ステップＳ４４０３）。
　所定のデバイスは、機能レジスタ情報を送信した後、または、ステップＳ４４０１において内部処理順序の機能レジスタ情報の読み出し要求または命令を受信しなかった場合に、内部処理順序の設定情報を受信したか否か判定する（ステップＳ４４０４）。所定のデバイスは、内部処理順序の設定情報を受信しなかった場合（ステップＳ４４０４；Ｎ）、ステップＳ４４０１を実行する。所定のデバイスは、内部処理順序の設定情報を受信した場合（ステップＳ４４０４；Ｙ）、内部処理完了まで待機する（ステップＳ４４０５）。
　続いて、所定のデバイスは、第２内部処理順序が指定されたか否か判定する（ステップＳ４４０６）。所定のデバイスは、第２内部処理順序が指定されなかった場合（ステップＳ４４０６；Ｎ）、第１内部処理順序が指定されたか否か判定する（ステップＳ４４０７）。所定のデバイスは、第１内部処理順序が指定されなかった場合（ステップＳ４４０７；Ｎ）、ステップＳ４４０１を実行する。
　所定のデバイスは、第１内部処理順序が指定された場合（ステップＳ４４０７；Ｙ）、第１内部処理順序を選択し実行する（ステップＳ４４０８、Ｓ４４１０）。一方、所定のデバイスは、第２内部処理順序が指定された場合（ステップＳ４４０６；Ｙ）、第２内部処理順序を選択し実行する（ステップＳ４４０９、Ｓ４４１０）。
　アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の保護部は、制御系通信または画像系通信のメッセージ認証（例えば、GMAC）またはメッセージ認証および暗号化または復号（例えば、GCM、CCM）に対する内部処理順序として、第１内部処理順序と第２内部処理順序とのうちの何れか一方を選択可能に構成されてもよい。例えば、事前合意、機能レジスタ（図２７２）、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）（図２７３）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。第1内部処理順序を初期設定またはデフォルト設定とし、何も指定が無ければ第1内部処理順序を基本的に選択するようにしてもよい。アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の制御系通信向けまたは画像系通信向け内部処理順序は、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）を介してSSMCに送信またはSSMCから送信された情報に基づいて選択されてもよい。アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の保護部は機能レジスタを含み、機能レジスタに格納される情報はSPDMメッセージ（例えば、Vendor defined SPDMメッセージ）などを介してSSMCに送信またはSSMCから送信され、機能レジスタは、保護部が選択可能なGMAC、GCM、またはCCMアルゴリズム向け内部処理順序を示す情報が格納されてもよい。制御系通信または画像系通信は、保護部によって選択されたGMAC、GCM、またはCCMアルゴリズム向け内部処理順序に基づいてメッセージ認証されてもよい。
　アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端の保護部は、暗号化処理または復号処理の実行要否を選択可能に構成され、送信する又は受信したデータ群に対して内部処理を実行するデータ順序が、暗号化処理または復号処理の実行時と非実行時とで異なってもよい。暗号化の要否を示す情報は、拡張パケットヘッダ（EXTENDED HEADER）に格納して送信または受信されてもよい。
　図２７４は、第１CCIモードにおける内部処理の切り替え処理の一例を説明するフローチャートである。図２７４には、所定のデバイスにおける処理が例示されている。なお、図２７４において破線で示した処理は、オプションである。
　所定のデバイスは、ループ処理を終了するか否か判定する（ステップＳ４５０１）。所定のデバイスは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４５０１；Ｙ）。所定のデバイスは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４５０１；Ｎ）、データを送信するか否か判定する（ステップＳ４５０２）。所定のデバイスは、データを送信しない場合（ステップＳ４５０２；Ｎ）、ステップ４５０１を実行する。所定のデバイスは、データを送信する場合（ステップＳ４５０２；Ｙ）、MAC値の演算（MAC演算）を開始する（ステップＳ４５０３）。
　続いて、所定のデバイスは、暗号化が必要か否か判定する（ステップＳ４５０４）。所定のデバイスは、暗号化が必要でない場合（ステップＳ４５０４；Ｎ）、第１内部処理順序を選択する（ステップＳ４５０５）。所定のデバイスは、暗号化が必要である場合（ステップＳ４５０４；Ｙ）、第２内部処理順序を選択し（ステップＳ４５０６）、所定の期間待機した後、暗号化を開始する（ステップＳ４５０７、Ｓ４５０８）。所定のデバイスは、暗号化を開始した場合、または、第１内部処理順序を選択した場合、MAC演算および暗号化の完了まで待機した後、データを送信する（ステップＳ４５０９、Ｓ４５１０）。
　図２７５は、第１CCIモードにおける内部処理の切り替え処理の一例を説明するフローチャートである。図２７５には、所定のデバイスにおける処理が例示されている。なお、図２７５において破線で示した処理は、オプションである。
　所定のデバイスは、ループ処理を終了するか否か判定する（ステップＳ４６０１）。所定のデバイスは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４６０１；Ｙ）。所定のデバイスは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４６０１；Ｎ）、データを送信するか否か判定する（ステップＳ４６０２）。所定のデバイスは、データを送信しない場合（ステップＳ４６０２；Ｎ）、ステップ４６０１を実行する。所定のデバイスは、データを送信する場合（ステップＳ４６０２；Ｙ）、MAC値の演算（MAC演算）を開始する（ステップＳ４６０３）。
　続いて、所定のデバイスは、復号が必要か否か判定する（ステップＳ４６０４）。所定のデバイスは、復号が必要でない場合（ステップＳ４６０４；Ｎ）、第１内部処理順序を選択する（ステップＳ４６０５）。所定のデバイスは、復号が必要である場合（ステップＳ４６０４；Ｙ）、第２内部処理順序を選択し（ステップＳ４６０６）、所定の期間待機した後、復号を開始する（ステップＳ４６０７、Ｓ４６０８）。所定のデバイスは、復号を開始した場合、または、第１内部処理順序を選択した場合、MAC演算および暗号化の完了まで待機した後、MAC検証に成功したか否か判定する（ステップＳ４６１０）。所定のデバイスは、MAC検証に成功しなかった場合、復号結果を破棄する（ステップＳ４６１１）。所定のデバイスは、MAC検証に成功した場合、復号結果を実行する（ステップＳ４６１２）。所定のデバイスは、復号結果を破棄した後、または復号結果を実行した後、メッセージを破棄し、MAC検証成否を送信する（ステップＳ４６１３、Ｓ４６１４）。
　GCM（GMACであってもよい）、CCM、またはCTRモードなどのアルゴリズムでは初期化ベクトルが必要になる。このとき、制御系通信の送信側と受信側との間（例えば、CCIのMaster側とSlave側との間）、または画像系通信の送信側と受信側との間で、初期化ベクトルの不一致（同期ズレ）が発生する可能性がある。初期化ベクトルの不一致に備える、または初期化ベクトルを再同期させるなどのために、必要に応じて又は周期的に、使用している最新の初期化ベクトルの一部または全部を通信相手に通知することが望ましい。特に第２CCIモードは、少なくともCCIのMaster側からはメッセージカウント値が送信されないCCIモードなので、初期化ベクトルの不一致が発生する可能性が他CCIモードよりも高い。そのため特に第２CCIモードは、最新の初期化ベクトルを通知する必要性が高い。
　GCM（GMACであってもよい）、CCM、およびCTRモードの何れかのアルゴリズムで用いられる又は用いられた最新の初期化ベクトルの一部または全部は、SSMC、アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端からの要求または命令に応じて、SPDM通信（例えば、SPDMメッセージ、Vendor defined SPDMメッセージ）、制御系通信または画像系通信を介して送信または受信されてもよい。 GCM（GMACであってもよい）、CCM、およびCTRモードの何れかのアルゴリズムで用いられる又は用いられた最新の制御系通信向け初期化ベクトルの一部または全部は、画像系通信（例えば、埋め込みデータ、画像データ、ユーザ定義データ）を介して送信または受信されてもよい。CTRモードによる暗号化またはCCMでは初期化ベクトル構成が必要になるが、上述した何れかのGCM（GMACであってもよい）向け初期化ベクトル構成の一部または全部が含まれていてもよく、実装の共通化またはアルゴリズムの切り替えなどを考慮する場合、GCM（GMACであってもよい）とCCMまたはCTRモードとの間で初期化ベクトル構成の一部または全部が共通化されていることが望ましい。
　図２７６は、内部処理の切り替え処理の一例を説明するフローチャートである。図２７６には、所定のデバイスにおける処理が例示されている。
　所定のデバイスは、ループ処理を終了するか否か判定する（ステップＳ４７０１）。所定のデバイスは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４７０１；Ｙ）。所定のデバイスは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４７０１；Ｎ）、初期化ベクトルを使用するか否か判定する（ステップＳ４７０２）。所定のデバイスは、初期化ベクトルを使用する場合（ステップＳ４７０２；Ｙ）、最新の初期化ベクトルを使用開始する（ステップＳ４７０３）。
　所定のデバイスは、最新の初期化ベクトルを使用開始する場合、または、初期化ベクトルを使用しない場合（ステップＳ４７０２；Ｎ）、初期化ベクトル送信の要求または命令を受信したか否か判定する（ステップＳ４７０４）。所定のデバイスは、初期化ベクトル送信の要求または命令を受信した場合（ステップＳ４７０４；Ｙ）、最新の初期化ベクトルを送信する（ステップＳ４７０５）。所定のデバイスは、最新の初期化ベクトルを送信する場合、または、初期化ベクトル送信の要求または命令を受信しなかった場合（ステップＳ４７０４；Ｎ）、初期化ベクトルの更新が必要か否か判定する（ステップＳ４７０６）。所定のデバイスは、初期化ベクトルの更新が必要ではない場合（ステップＳ４７０６；Ｎ）、ステップＳ４７０１を実行する。所定のデバイスは、初期化ベクトルの更新が必要である場合（ステップＳ４７０６；Ｙ）、初期化ベクトルを更新した後（ステップＳ４７０７）、ステップＳ４７０１を実行する。
　図２７７、図２７８は、上記実施の形態およびその変形例におけるライトデータのパケット構成の一例を示したものである。図２７７、図２７８には、メッセージ内のメッセージ認証対象のＯＮ／ＯＦＦまたは暗号化対象のＯＮ／ＯＦＦの一例が示されている。
　制御系通信は、レジスタアドレスまたは拡張パケットヘッダ（EXTENDED HEADER）の送信または受信と、レジスタアドレスまたは拡張パケットヘッダ（EXTENDED HEADER）に対応する書き込みデータまたは読み出しデータの送信または受信とを含む。レジスタアドレスまたは拡張パケットヘッダ（EXTENDED HEADER）は、制御系通信のメッセージ認証で保護される。イメージセンサまたはブリッジ他端の保護部は、レジスタアドレスまたは拡張パケットヘッダ（EXTENDED HEADER）の情報に基づいて、書き込みデータまたは読み出しデータに対するメッセージ認証または暗号化の要否を判断してもよい。書き込みデータまたは読み出しデータの一部または全部をメッセージ認証対象から除外することによって、少なくとも拡張パケットヘッダ（EXTENDED HEADER）に対する改竄を対策することができる。さらに、メッセージ認証対象から除外された書き込みデータまたは読み出しデータを、MAC値に影響を与えずに自由に変更できる利点がある。これらの例示における最終行も、メッセージ認証対象から除外されてもよい。書き込みデータまたは読み出しデータの一部または全部を暗号化対象から除外することによって、部分的な暗号化の自由度が向上され利点がある。
　部分的にメッセージ認証の対象から除外するか否かは、メッセージ認証ポリシーであって、例えば、事前合意、機能レジスタ、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。このことは、制御系通信または画像系通信に適用できる。画像系通信の場合、図２２７、図２３０、または図２３２などにおける、フレームスタート（FS）、フレームエンド（FE）、および埋込データ（Emb Data）のパケットデータと拡張パケットヘッダ（ePH）とは、非連続データなので改竄対策が必須であることから全領域をMAC対象にすることが望ましいものの、少なくとも画像データ（Img Data）のパケットデータについては、連続データなので連続性によって改竄検知できる可能性が高いことから全領域をMAC対象にしないようにしてもよい。画像データのパケットデータの一部をMAC対象（Covered by MAC）とし、画像データのパケットデータの残りをMAC対象外（Not covered by MAC）としてもよく、つまり、画像データのパケットデータは一部が部分的にメッセージ認証の対象から除外されてもよい。この場合、所定時間（例えば、MAC値の送信周期）内にMAC値を演算する必要があるMAC対象領域を小さくできるので、MAC演算に対する負荷も小さくなり、アルゴリズムの実装が容易になる。画像データのパケットデータの一部を暗号化または復号の対象とし、画像データのパケットデータの残りを暗号化または復号の対象外としてもよく、つまり、画像データのパケットデータは一部が部分的に暗号化または復号の対象から除外されてもよい。MAC対象領域と暗号化または復号の対象領域とは一致していてもよいし、一致していなくてもよい。CMACまたはHMACによるMAC演算は並列化できないが、CTRモードによる暗号化または復号の演算は並列化できるので、MAC対象領域よりも暗号化または復号の対象領域を大きくすることが可能である。ただし、MACアルゴリズムとしてGMACが適用されてもよいし、暗号化アルゴリズムとしてCBCモードが適用されてもよいし、AEADアルゴリズムとしてGCMが適用されてもよい。画像データのパケットデータの一部を部分的にメッセージ認証の対象から除外し、画像データのパケットデータの残りをメッセージ認証の対象とし、画像データのパケットデータの全部を暗号化または復号の対象としてもよい。この場合、アルゴリズムの実装を容易にしつつ、画像データが含むプライバシー情報等を暗号化および復号によって適切に保護できる。画像データのパケットデータに対して部分的にメッセージ認証の対象から除外するMAC除外モードの種類（例えば、第１MAC除外モード、第２MAC除外モード、第３MAC除外モード）は、メッセージ認証ポリシーであって、例えば、事前合意、機能レジスタ、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。例えば、画像データのパケットデータにおける各ラインに対して、時系列順に偶数本目のライン（例えば、ライン０、ライン２、ライン４）をメッセージ認証の対象とし、時系列順に奇数本目のライン（例えば、ライン１、ライン３、ライン５）をメッセージ認証の対象から除外するMAC除外モードを、第１MAC除外モードとしてもよい（ただし、偶奇が反転でもよい）。例えば、画像データのパケットデータにおける各ラインに対して、時系列順に３の倍数本目のライン（例えば、ライン０、ライン３、ライン６）をメッセージ認証の対象とし、それ以外のライン（例えば、ライン１、ライン２、ライン４、ライン５、ライン７、ライン８）をメッセージ認証の対象から除外するMAC除外モードを、第２MAC除外モードとしてもよい。例えば、画像データのパケットデータにおける各ラインに対して、時系列順に４の倍数本目のライン（例えば、ライン０、ライン４、ライン８）をメッセージ認証の対象とし、それ以外のライン（例えば、ライン１、ライン２、ライン３、ライン５、ライン６、ライン７）をメッセージ認証の対象から除外するMAC除外モードを、第３MAC除外モードとしてもよい。これら画像縦方向（ライン垂直方向）に対してのMAC除外モードは一例であって、例えば、画像横方向（ライン水平方向）に対してのMAC除外モードとして定義してもよい。
　なお、図２７９に示したように、書き込みデータがメッセージ認証対象から除外されてもよい。また、図２８０に示したように、書き込みデータ、SLAVE ADDRESSおよびレジスタアドレス（RegisterAddress）がメッセージ認証対象から除外されてもよい。このとき、MAC処理対象が、例えば、事前合意、機能レジスタ（図２８１）、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）（図２８２）、拡張パケットヘッダ（EXTENDED HEADER）（図２８３）などを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。
　図２８４は、その他のメッセージ認証ポリシー（暗号化ポリシー）による演算処理の一例を説明するフローチャートである。図２８４には、アプリケーションプロセッサ、イメージセンサ、ディスプレイ、ブリッジ一端、またはブリッジ他端（以降では、「所定のデバイス」と称する）における処理が例示されている。なお、図２８４において破線で示した処理は、オプションである。
　所定のデバイスは、ループ処理を終了するか否か判定する（ステップＳ４８０１）。所定のデバイスは、例えば、通信の終了命令を受信した場合に、ループ処理を終了する（ステップＳ４８０１；Ｙ）。所定のデバイスは、例えば、通信の終了命令を受信しない場合に、ループ処理を終了せず（ステップＳ４８０１；Ｎ）、メッセージ認証ポリシーの機能レジスタ情報の読み出し要求または命令を受信したか否か判定する（ステップＳ４８０２）。
　所定のデバイスは、メッセージ認証ポリシーの機能レジスタ情報の読み出し要求または命令を受信した場合、機能レジスタ情報を送信する（ステップＳ４８０２）。所定のデバイスは、機能レジスタ情報を送信した後、または、メッセージ認証ポリシーの機能レジスタ情報の読み出し要求または命令を受信しなかった場合（ステップＳ４８０２；Ｎ）、メッセージ認証ポリシーの設定情報を受信したか否か判定する（ステップＳ４８０３）。
　所定のデバイスは、メッセージ認証ポリシーの設定情報を受信しなかった場合（ステップＳ４８０４；Ｎ）、ステップＳ４８０１を実行する。所定のデバイスは、メッセージ認証ポリシーの設定情報を受信した場合（ステップＳ４８０４；Ｙ）、内部処理完了まで待機する（ステップＳ４８０５）。続いて、所定のデバイスは、第２メッセージ認証ポリシーが指定されたか否か判定する（ステップＳ４８０６）。所定のデバイスは、第２メッセージ認証ポリシーが指定された場合（ステップＳ４８０６；Ｙ）、第２メッセージ認証ポリシーを選択する（ステップＳ４８０７）。
　所定のデバイスは、第２メッセージ認証ポリシーが指定されなかった場合（ステップＳ４８０６；Ｎ）、第３メッセージ認証ポリシーが指定されたか否か判定する（ステップＳ４８０８）。所定のデバイスは、第３メッセージ認証ポリシーが指定された場合（ステップＳ４８０８；Ｙ）、第３メッセージ認証ポリシーを選択する（ステップＳ４８０９）。所定のデバイスは、第３メッセージ認証ポリシーが指定されなかった場合（ステップＳ４８０８；Ｎ）、第４メッセージ認証ポリシーが指定されたか否か判定する（ステップＳ４８１０）。所定のデバイスは、第４メッセージ認証ポリシーが指定された場合（ステップＳ４８１０；Ｙ）、第４メッセージ認証ポリシーを選択する（ステップＳ４８１１）。所定のデバイスは、第４メッセージ認証ポリシーが指定されなかった場合（ステップＳ４８１０；Ｎ）、第１メッセージ認証ポリシーが指定されたか否か判定する（ステップＳ４８１２）。所定のデバイスは、第１メッセージ認証ポリシーが指定された場合（ステップＳ４８１２；Ｙ）、第１メッセージ認証ポリシーを選択する（ステップＳ４８１３）。所定のデバイスは、第１メッセージ認証ポリシーが指定されなかった場合（ステップＳ４８１２；Ｎ）、ステップＳ４８０１を実行する。
　所定のデバイスは、第２メッセージ認証ポリシー、第３メッセージ認証ポリシー、第４メッセージ認証ポリシーまたは第１メッセージ認証ポリシーを選択した場合（ステップＳ４８０７、Ｓ４８０９、Ｓ４８１１、Ｓ４８１３）、内部処理を開始した後（ステップＳ４８１４）、ステップＳ４８０１を実行する。
　図２８５、図２８６および図２８７は、メッセージ認証ポリシーの一例を表したものである。MAC only（No encryption）とEncrypt-then-MACとMAC-then-EncryptとEncrypt-and-MACとのうちの少なくとも何れかをメッセージ認証ポリシー（暗号化ポリシーと称してもよい）として選択可能に構成されてもよい。メッセージ認証ポリシー自体の詳細は、上述した通りなので省略する。第1メッセージ認証ポリシー（初期設定またはデフォルト設定）は、Encrypt-then-MAC、MAC-then-Encrypt、およびEncrypt-and-MACの何れが選択されてもよい。第1メッセージ認証ポリシー（初期設定またはデフォルト設定）は、アルゴリズム次第であってもよい。CBCモードまたはCTRモードによる暗号文を復号するために送信または受信される初期化ベクトルIVがメッセージ認証対象ではない場合、送信または受信された初期化ベクトルに対する改竄を検出するために、送信または受信された初期化ベクトルが改竄されると復号結果の平文も改竄されるのでMAC検証がNGになる、MAC-then-Encryptを選択することが望ましい。CBCモードまたはCTRモードによる暗号文を復号するために送信または受信される初期化ベクトルIVがメッセージ認証対象ではない場合、かつEncrypt-then-MACの場合、初期化ベクトルが改竄されても暗号文は改竄されないのでMAC検証はOKとなるが、初期化ベクトルは改竄されるので復号結果の平文は改竄される。CBCモードまたはCTRモードによる暗号文を復号するために送信または受信される初期化ベクトルIVがメッセージ認証対象である場合、Enc-then-MACポリシー次第だが、MAC-then-EncryptとEncrypt-then-MACとの何れを選択しても問題ない。GCMによる暗号化または復号の場合、Encrypt-then-MACであることが望ましい。
　図２８８は、機能レジスタの一例を表したものである。図２８９は、Vendor defined SPDMメッセージの一例を表したものである。Encrypt-then-MACの暗号化は、平文（Plaintext）から暗号文（Ciphertext）に暗号化し、暗号文に対するMAC値を演算する。つまり、平文に対する暗号化を開始した後にMAC演算を開始する。Encrypt-then-MACの復号は、暗号文に対するMAC値を演算し、暗号文から平文に復号する。つまり、暗号文に対するMAC演算を開始した後に復号を開始する。Encrypt-and-MACの暗号化は、平文から暗号文に暗号化しつつ、平文に対するMAC値を演算する。つまり、平文に対する暗号化の開始とMAC演算の開始とが、同一または略同一である。または、平文に対するMAC値を演算し、平文から暗号文に暗号化する。つまり、平文に対するMAC演算を開始した後に暗号化を開始する。Encrypt-and-MACの復号は、暗号文から平文に復号し、平文に対するMAC値を演算する。つまり、暗号文に対する復号を開始した後にMAC演算を開始する。MAC-then-Encryptの暗号化は、平文に対するMAC値を演算し、平文およびMAC値から暗号文に暗号化する。つまり、平文に対するMAC演算を開始した後に暗号化を開始する。MAC-then-Encryptの復号は、暗号文から平文およびMAC値に復号し、平文に対するMAC値を演算する。つまり、暗号文に対する復号を開始した後にMAC演算を開始する。書き込みデータまたは読み出しデータの復号結果の実行または反映（Enc-then-MACポリシー）が、常時（Always、No rejection）であることをEncrypt-then-MAC-0と定義してもよいし、MAC検証に成功した場合のみ（Only when MAC matched）であることをEncrypt-then-MAC-1と定義してもよいし、これらの定義が逆であってもよい。書き込みデータまたは読み出しデータの暗号化開始または復号開始（Enc-then-MACポリシー）が、ライン単位（ライン毎に初期化ベクトル内のメッセージカウント値をインクリメントする）であることをEncrypt-then-MAC-0と定義してもよいし、フレーム単位（フレーム毎に初期化ベクトル内のフレーム番号をインクリメントする）であることをEncrypt-then-MAC-1と定義してもよいし、これらの定義が逆であってもよい。DSP0277仕様に準拠または非準拠なVendor defined Secured Messageにおけるメッセージ認証対象かつ平文かつヘッダの領域（領域の直前または領域内）にベンダ固有領域（Vendor specific）、ベンダ定義領域（Vendor Defined）、ユーザ定義領域（User Defined）、またはリザーブド領域（Reserved for future use）などが追加されてもよいことを上述したが、メッセージ認証対象かつ平文かつヘッダの領域の直前にこれら何れかの領域が追加されると、DSP0277仕様外の領域になるので、その領域はメッセージ認証対象外かつ平文かつヘッダの領域になる場合がある。このメッセージ認証対象外かつ平文かつヘッダの領域内にCBCモードまたはCTRモードに用いられる初期化ベクトルが格納される場合、上述した通りMAC-the-Encであることが望ましい。メッセージ認証対象外かつ平文かつヘッダの領域には、メッセージ認証対象かつ暗号化対象の領域に適用される暗号化モードを識別するための情報（例えば、暗号化モードの種類に応じて定義されるビット情報またはID情報（例えば、EncID））を含めることが望ましい。ただし、NEGOTIATE_ALGORITHMS要求およびALGORITHMS応答と事前合意（Private contract）との何れかによって、メッセージ認証対象かつ暗号化対象の領域に適用される暗号化モードがSPDMリクエスタとSPDMレスポンダとの間で認識合わせ（識別）されている場合、メッセージ認証対象かつ暗号化対象の領域に適用される暗号化モードを識別するための情報を、メッセージ認証対象外かつ平文かつヘッダの領域に含める必要はない。これらの場合、例えば、暗号化モードがCBCモードであればメッセージ認証対象外かつ平文かつヘッダの領域に初期化ベクトルを格納するフォーマットを選択し、暗号化モードがCBCモード以外（例えば、GCMまたはCTRモード）であればメッセージ認証対象外かつ平文かつヘッダの領域に初期化ベクトルを格納しないフォーマットを選択することが可能になるので、暗号化モードがCBCモード以外の場合のオーバーヘッドを小さくできる。また、例えば、暗号化モードがCBCモードであればMAC-then-Encを選択し、暗号化モードがCBCモード以外（例えば、GCMまたはCTRモード）であればEncrypt-then-MACを選択することが可能になるので、暗号化モードに応じて適切なメッセージ認証ポリシーを選択できる。
　図２９０は、初期化ベクトルの一例（GMAC-GCM-CTR Unified-IV）を表したものである。128 bits Initialization Vector for AES-CTR-modeの構成は、96 bits Initialization Vector for AES-GCM/GMACの構成の一部または全部を含んでもよい。128 bits Initial Counter Block for AES-GCMと128 bits Initialization Vector for AES-CTR-modeとでPre-counter 32 bitsは、同じInitial valueの構成であってもよいし、異なるInitial valueの構成であってもよい。AES-CTRモードの場合、Initial value（初期値）を0にすると32ビットのカウンタをフル活用することが可能になる。一方、AES-CTRモードのInitial value（初期値）とAES-GCMのInitial value（初期値）とで構成を同一にすることによって、カウンタを再利用するようにしてもよい。
　図２９１、図２９２は、初期化ベクトルの一例を表したものである。ライン単位（Per-Line）、複数ライン単位（Per-Multi-Line）、またはフレーム単位（Per-Frame）のメッセージ認証（MAC）または暗号化（または復号）に用いられる初期化ベクトル構成の種類を複数設けて、その何れかが選択されるようにしてもよい。初期化ベクトル構成は、例えば、事前合意、機能レジスタ、SPDMメッセージ（例えば、Vendor defined SPDMメッセージ）、拡張パケットヘッダ（EXTENDED HEADER）、またはTRIGGER DESCRIPTORなどを介してCCIのMaster側とSlave側とで認識合わせされてもよいし、画像系データ送信側と画像系データ受信側とで認識合わせされてもよい。複数ライン単位のメッセージ認証（MAC）または暗号化（または復号）の場合、複数ライン単位ライン群のうちの最初のラインに対応するメッセージカウント値が、初期化ベクトル内のメッセージカウント値としても用いられてもよい。フレーム単位のメッセージ認証（MAC）または暗号化（または復号）の場合、フレーム単位ライン群のうちの最初のラインに対応するメッセージカウント値が、初期化ベクトル内のメッセージカウント値としても用いられてもよい。画像系通信の場合は初期化ベクトル内のMode（例えば、Reserved、CCI-mode、MACモード（Read/WriteモードまたはCCIモードをMACモードとしてもよい）が固定値として例えば0（Mode=02）に設定されてもよいし、制御系通信の場合は初期化ベクトル内のeVCが固定値として例えば0（eVC=06）に設定されてもよい。初期化ベクトル内のModeは2ビット以上（例えば、8ビット）が割り当てられてもよく、その場合にeVCを初期化ベクトル内に割り当てないようにしてもよい。
　初期化ベクトルにおけるeVCとModeとの順番は入れ替えてもよいし、初期化ベクトルにおけるeVCの一部または全部をModeまたは0（例えば、06）に置き換えてもよいし、初期化ベクトルにおけるSalt、Additional message counter、またはAdditional frame numberの一部または全部をModeまたは0（例えば、032、024）に置き換えてもよいし、初期化ベクトルにおけるModeの一部または全部を0（例えば、02）に置き換えてもよい。図２９２は、CCI-mode-1-ReadとCCI-mode-3-Readとに同じビットを割り当て、CCI-mode-1-WriteとCCI-mode-3-Writeとに同じビットを割り当てる例だが、第１CCIモード（CCI-mode-1）と第３CCIモード（CCI-mode-3）とで割り当てるビットを異ならせてもよい。Saltは、固定値であってもよく、例えば0（032）であってもよい。例えばSPDMセッションまたはSPDMメッセージ（例えば、Vendor defined SPDMメッセージ）を省略したシステムが構成される場合などでは、Saltを固定値にせざるを得ない状況もある。図２９２の定義は、IV-Mode value example for Control Plane（制御系通信）の定義としてもよいし、MACモードの定義として、0b00: IV-Mode is Write-Mode with either Per-Transaction (CCI-mode-1) or Per-Multi-Transaction (CCI-mode-3)、0b01: IV-Mode is Read-Mode with either Per-Transaction (CCI-mode-1) or Per-Multi-Transaction (CCI-mode-3)、0b10: IV-Mode is Write-Mode with Per-Frame (CCI-mode-2)、0b11: IV-Mode is Read-Mode with Per-Frame (CCI-mode-2)、と定義してもよい。ここで、Per-Transactionは１トランザクション単位、Per-Multi-Transactionは複数トランザクション単位、Per-Frameは１フレーム単位である。図２９２の定義は、IV-Mode value example for Data Plane（画像系通信）の定義としてもよいし、MACモードの定義として、0b00: IV-Mode is Per-Line（１ライン単位）、0b01: IV-Mode is Per-Multi-Line（複数ライン単位）、0b10: IV-Mode is Per-Frame（１フレーム単位）、0b11: IV-Mode is Partial-Frame-ROI（１ROI単位）、と定義してもよい。Per-Line（１ライン単位）は、Per-Message（１メッセージ単位）またはPer-Transaction（１トランザクション単位）と解釈してもよいし、Per-Multi-Line（複数ライン単位）は、Per-Multi-Message（複数メッセージ単位）またはPer-Multi-Transaction（複数トランザクション単位）と解釈してもよいし、逆もまた同様である。ROIはRegion of Interestの略語である。画像系通信における各１フレーム内のデータに対してMAC対象とする一部領域（限定領域）を制御系通信（例えば、SPDMセッション、Control Planeセッション）または事前合意などによって指定し、その領域のMAC値を演算し、そのMAC値を拡張パケットフッタまたは埋め込みデータに格納して画像系データ送信側から画像系データ受信側へ送信することをPartial-Frame-ROI MACモードと称する。Partial-Frame-ROI MACモードにおけるMAC値の送信周期は、フレームの送信周期と同一であってもよいし、フレームの送信周期より短くてもよい。Partial-Frame-ROI MACモードに限らず、他のMACモード（Per-Line MACモード、Per-Multi-Line MACモード、Per-Frame MACモード）も、MAC値を拡張パケットフッタまたは埋め込みデータに格納して画像系データ送信側から画像系データ受信側へ送信してもよい。Per-Multi-Line（複数ライン単位）MACモードは、メッセージ認証（MAC）または暗号化（または復号）の対象とするライン数が固定とは限らず、可変であってもよい。可変な場合、Per-Multi-Line（複数ライン単位）MACモードは、１ライン単位のメッセージ認証（MAC）または暗号化（または復号）を包含してもよい。初期化ベクトルにおけるmessage counterは、Defined by Modeに置き換えてもよく、Pre-LineまたはPre-Multi-LineのMACモードである場合に「message counter」を選択し、Pre-FrameのMACモードである場合に「Always 016」を選択し、Partial-Frame-ROIのMACモードである場合に「ROI Number」を選択するようにしてもよい。また、message counter（メッセージカウンタ値またはメッセージカウント値）の初期値は、上述した一例の０ではなく１としてもよい。これらの場合、Pre-Line、Pre-Multi-Line、Pre-Frame、およびPartial-Frame-ROIのMACモードの間で初期化ベクトル構成を一本化できるので、機能レジスタに定義すべき初期化ベクトル構成の種類数を削減できることに加え、２つ以上のMACモードを切り替えまたは同時実行することが可能になる。ROI Number（ROI番号）は、１つのフレーム内に複数のROIを設ける場合に、それぞれのROIを識別するための番号である。
　ブロック図やフローチャートなどの何れかの図面を構成する要素のタイミングまたは位置は一例であり、異なるように構成されてもよい。各例で説明した実施の形態は、種々の変形例が存在する。即ち、説明した各例の構成要素は、一部が省略されてもよく、一部または全部が変化していてもよく、一部または全部が変更されていてもよい。また、一部が他の構成要素で置き換えられていてもよく、一部または全部に他の構成要素が追加されていてもよい。　更には、構成要素の一部または全部が複数に分割されていてもよく、一部または全部が複数に分離されていてもよく、分割または分離された複数の構成要素の少なくとも一部で機能や特徴を異ならせていてもよい。更に、各構成要素の少なくとも一部を移動させて異なる実施の形態としてもよい。更にまた、各構成要素の少なくとも一部の組み合わせに結合要素や中継要素を加えて異なる実施の形態としてもよい。加えて、各構成要素の少なくとも一部の組み合わせに切り替え機能または選択機能を加えて異なる実施の形態としてもよい。本実施の形態は、説明した各例で示した構成に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。なお、本明細書に記載された効果はあくまでも例示であって限定されるものではなく、また他の効果があってもよい。本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に説明した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。また、例えば、説明したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。また、例えば、フローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が説明した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、説明した任意の本技術の一部または全部を、説明していない他の技術と併用して実施することもできる。
　＜コンピュータの構成例＞
　図２９２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
　コンピュータにおいて、CPU（Central Processing Unit）２２０１，ROM（Read Only Memory）２２０２，RAM（Random Access Memory）２２０３、およびEEPROM（Electronically Erasable and Programmable Read Only Memory）２２０４は、バス２２０５により相互に接続されている。バス２２０５には、さらに、入出力インタフェース２２０６が接続されており、入出力インタフェース２２０６が外部に接続される。
　以上のように構成されるコンピュータでは、CPU２２０１が、例えば、ROM２２０２およびEEPROM２２０４に記憶されているプログラムを、バス２２０５を介してRAM２２０３にロードして実行することにより、上述した一連の処理が行われる。また、コンピュータ（CPU２２０１）が実行するプログラムは、ROM２２０２に予め書き込んでおく他、入出力インタフェース２２０６を介して外部からEEPROM２２０４にインストールしたり、更新したりすることができる。
　ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
　また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
　さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
　また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
　また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
　また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
　なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
　なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
　＜構成の組み合わせ例＞
　なお、本技術は以下のような構成も取ることができる。
（１）
　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
　前記保護部は、
　　前記第１通信を利用して第１セッション鍵を導出または受信し、
　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
　　前記第２セッション鍵を前記第２通信の暗号化、復号またはメッセージ認証に使用し、
　前記第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、前記第１デバイスと前記第３デバイスと間の第３通信と、前記第１通信とにおいて互いに異なる
　情報処理装置。
（２）
　前記第１通信の通信経路は、前記第３通信の通信経路よりも長く、
　前記総通信回数もしくは前記総通信データ量は、前記第３通信よりも前記第１通信において少ない
　（１）に記載の情報処理装置。
（３）
　前記保護部は、
　前記第２通信を使用して、前記第２セッション鍵の使用開始タイミング指定を送信または受信し、
　前記第３通信を使用して、前記使用開始タイミング指定または前記使用開始タイミング指定に関する情報を送信または受信する
　（１）または（２）に記載の情報処理装置。
（４）
　前記使用開始タイミング指定または前記使用開始タイミング指定に関する情報は、前記第３通信のＥＲＲＯＲ応答メッセージ、ＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答メッセージおよびＶｅｎｄｏｒ ｄｅｆｉｎｅｄ ＳＰＤＭメッセージのうちの少なくともいずれかによって、前記第３デバイスから前記第１デバイスに送信される
　（３）に記載の情報処理装置。
（５）
　前記保護部は、前記第２通信を使用して、前記第２通信に関連する特異メッセージを送信または受信する
　（１）ないし（４）のいずれか１つに記載の情報処理装置。
（６）
　前記保護部は、前記第３通信を使用して、前記特異メッセージまたは前記特異メッセージに関連する情報を送信または受信する
　（５）に記載の情報処理装置。
（７）
　前記特異メッセージまたは前記特異メッセージに関連する情報は、前記第３通信のＥＲＲＯＲ応答メッセージ、ＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答メッセージおよびＶｅｎｄｏｒ ｄｅｆｉｎｅｄ ＳＰＤＭメッセージのうちの少なくともいずれかによって、前記第３デバイスから前記第１デバイスに送信される
　（５）または（６）に記載の情報処理装置。
（８）
　（１）ないし（７）のいずれか１つに記載の情報処理装置。
（９）
　前記第３デバイスは、前記第３通信を使用して前記第２セッション鍵を受信し、前記第２セッション鍵を前記第２通信の前記暗号化、復号、またはメッセージ認証に使用し、
　前記第２通信は、双方向通信であり、
　前記第２デバイスまたは前記第３デバイスは、ブリッジ装置の一部または全部であり、
　前記第２セッション鍵は、前記第１通信を使用して送信または受信された後に前記第３通信を使用して送信または受信される
　（１）ないし（７）のいずれか１つに記載の情報処理装置。
（１０）
　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵とは異なる乱数を送信または受信する
　（１）ないし（９）のいずれか１つに記載の情報処理装置。
（１１）
　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵の使用状況が確認される周期に関連する情報、または前記第２セッション鍵が更新される周期に関連する情報を送信または受信する
　（１）ないし（１０）のいずれか１つに記載の情報処理装置。
（１２）
　前記保護部は、前記第１通信または前記第３通信において、前記第２通信のメッセージカウンタに関連する情報を送信または受信する
　（１）ないし（１１）のいずれか１つに記載の情報処理装置。
（１３）
　前記保護部は、メッセージカウンタと前記メッセージカウンタに応じて変化する追加メッセージカウンタとを含み、
　前記メッセージカウンタのカウント値と前記追加メッセージカウンタのカウント値とは、前記第２セッション鍵を使用する前記メッセージ認証によって保護されるメッセージの一部であり、
　前記保護部は、前記第２通信において、前記メッセージカウンタのカウント値を送信または受信する
　（１）ないし（１２）のいずれか１つに記載の情報処理装置。
（１４）
　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵の使用開始を要求するメッセージを送信または受信する
　（１）ないし（１３）のいずれか１つに記載の情報処理装置。
（１５）
　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵の使用終了を要求するメッセージを送信または受信する
　（１）ないし（１４）のいずれか１つに記載の情報処理装置。
（１６）
　前記第２通信の前記暗号化、復号またはメッセージ認証には、ＭＡＣモードを含む初期化ベクトルが用いられる
　（１）ないし（１５）のいずれか１つに記載の情報処理装置。
（１７）
　前記保護部は、前記第２通信において、画像データおよび前記画像データに関連する埋め込みデータの送信または受信を行い、
　前記埋め込みデータは、フレーム単位毎に変化するナンス情報の一部もしくは全部を含む
　（１）ないし（１６）のいずれか１つに記載の情報処理装置。
（１８）
　前記ナンス情報は、ＣＭＡＣまたはＨＭＡＣによって保護される
　（１７）に記載の情報処理装置。
（１９）
　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
　前記保護部は、
　　前記第１通信を利用して第１セッション鍵を導出または受信し、
　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
　　前記第２セッション鍵を前記第２通信の暗号化、復号またはメッセージ認証に使用し、
　前記第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、前記第１デバイスと前記第３デバイスと間の第３通信と、前記第１通信とにおいて互いに異なる
　移動体装置。
（２０）
　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
　前記保護部は、
　　前記第１通信を利用して第１セッション鍵を導出または受信し、
　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
　　前記第２セッション鍵を前記第２通信の暗号化、復号またはメッセージ認証に使用し、
　前記第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、前記第１デバイスと前記第３デバイスと間の第３通信と、前記第１通信とにおいて互いに異なる
　通信システム。
（２１）
　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
　前記保護部は、
　　前記第１通信を利用して第１セッション鍵を導出または受信し、
　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
　　前記第２セッション鍵を前記第２通信のメッセージ認証に使用し、
　　第１メッセージ認証ポリシーおよび第２メッセージ認証ポリシーのうち何れか一方を選択した前記第２通信におけるメッセージ認証ポリシーに基づいて前記第２通信の前記メッセージ認証を検証する
　情報処理装置。
（２２）
　前記保護部は、前記第１通信を介して送信または受信された情報に基づいて前記第２通信におけるメッセージ認証ポリシーを選択する
　（１）ないし（２１）のいずれか１つに記載の情報処理装置。
（２３）
　前記保護部は、機能レジスタを含み、前記機能レジスタに格納される情報を、前記第１通信を介して送信または受信し、
　前記機能レジスタには、前記保護部が選択可能なメッセージ認証ポリシー候補を示す情報が格納され、
　前記メッセージ認証ポリシー候補は、前記第１メッセージ認証ポリシーおよび前記第２メッセージ認証ポリシーのうち少なくとも何れかであり、
　前記保護部は、前記機能レジスタに格納された、前記メッセージ認証ポリシー候補の中から、前記第２通信における前記メッセージ認証ポリシーを選択する
　（２１）または（２２）記載の情報処理装置。
（２４）
　前記保護部は、機能レジスタを含み、前記機能レジスタに格納される情報を、前記第１通信を介して送信または受信し、
　前記機能レジスタには、前記第２通信の前記メッセージ認証に対して前記保護部が保持できるデータ量上限に関連する情報が格納され、
　前記保護部は、前記データ量上限を超えない範囲内のデータ群に対して前記第２通信の前記メッセージ認証を検証する
　（１）ないし（２３）のいずれか１つに記載の情報処理装置。
（２５）
　前記保護部は、前記第２通信の前記メッセージ認証に対する内部処理順序として、第１内部処理順序および第２内部処理順序のうち何れか一方を選択する
　（１）ないし（２４）のいずれか１つに記載の情報処理装置。
（２６）
　前記保護部は、前記第２通信を使用して、メッセージ群または拡張パケットヘッダの送信または受信を行い、
　前記メッセージ群における最終メッセージまたは前記拡張パケットヘッダが、ＭＡＣ演算またはＣＲＣ演算を完了できるか否かを示す情報を含む
　（１）ないし（２５）のいずれか１つに記載の情報処理装置。
（２７）      
　前記保護部は、
　前記第２セッション鍵を前記第２通信の少なくとも暗号化もしくは復号に使用し、
　ＧＣＭ、ＣＣＭ、ＣＴＲモードおよびＣＢＣモードのうちのいずれかのアルゴリズムに基づいて前記暗号化もしくは復号を行う
　（１）ないし（２６）のいずれか１つに記載の情報処理装置。
（２８）
　前記保護部は、前記第２通信の前記暗号化、復号またはメッセージ認証で用いられるまたは用いられた最新の初期化ベクトルを、前記第１デバイスまたは前記第３デバイスからの要求または命令に応じて、前記第１通信または前記第２通信を介して送信または受信する
　（１）ないし（２７）のいずれか１つに記載の情報処理装置。
（２９）
　前記第２通信は、画像データおよび埋め込みデータを送信または受信する画像系通信を制御する通信であり、
　前記保護部は、前記第２通信の前記暗号化、復号またはメッセージ認証で用いられるまたは用いられた最新の初期化ベクトルを、前記画像系通信を介して送信または受信する
　（１）ないし（２８）のいずれか１つに記載の情報処理装置。
（３０）
　前記保護部は、前記第２通信を使用して、メッセージ群または拡張パケットヘッダの送信または受信を行い、
　前記メッセージ群における最終メッセージまたは前記拡張パケットヘッダが、前記第２通信の前記復号を開始できるか否かを示す情報を含む
　（１）ないし（２９）のいずれか１つに記載の情報処理装置。
（３１）
　前記保護部は、前記第２通信の前記復号の対象となる暗号化されたデータを含むデータ群に対してＣＲＣ値を演算する
　（１）ないし（３０）のいずれか１つに記載の情報処理装置。
（３２）
　前記保護部は、送信するまたは受信したデータ群とは異なるデータ順序で内部処理を実行する
　（１）ないし（３１）のいずれか１つに記載の情報処理装置。
（３３）
　前記保護部は、メッセージカウンタ値、ＭＡＣ値、もしくは初期化ベクトルが格納されるレジスタアドレスの受信、メッセージカウンタ値、ＭＡＣ値、もしくは初期化ベクトルの受信、またはメッセージカウンタ値もしくはＭＡＣ値の検証成功に応じて、前記第２通信の前記復号を開始する
　（１）ないし（３２）のいずれか１つに記載の情報処理装置。
（３４）
　前記保護部は、暗号化されたデータの受信開始からそのメッセージ認証が完了するまでの間、後続の暗号化されたデータのみを新たなメッセージ認証対象とする
　（１）ないし（３３）のいずれか１つに記載の情報処理装置。
（３５）
　前記保護部は、
　前記第２通信の前記暗号化または前記復号の実行要否を選択し、
　送信するまたは受信したデータ群に対して内部処理を実行する順序を、前記第２通信の前記暗号化または前記復号の実行時と非実行時とで異ならせる
　（１）ないし（３４）に記載の情報処理装置。
（３６）
　前記保護部は、前記第２通信を使用して、レジスタアドレスまたは拡張パケットヘッダの送信または受信を行い、
　前記レジスタアドレスまたは前記拡張パケットヘッダに対応する書き込みデータまたは読み出しデータの送信または受信を行い、
　前記レジスタアドレスまたは前記拡張パケットヘッダは、前記第２通信の前記メッセージ認証で保護され、
　前記保護部は、前記レジスタアドレスまたは前記拡張パケットヘッダの情報に基づいて、前記書き込みデータまたは前記読み出しデータに対する前記メッセージ認証または前記暗号化の要否を判断する
　（１）ないし（３５）のいずれか１つに記載の情報処理装置。
（３７）
　前記保護部は、前記第２通信におけるメッセージ認証ポリシーを、前記第３デバイスと前記第２デバイスとの間の事前合意によって選択する
　（１）ないし（３６）のいずれか１つに記載の情報処理装置。
（３８）
　前記第１デバイスと前記第３デバイスとは互いに別体、または互いに同一である
　（１）ないし（３７）のいずれか１つに記載の情報処理装置。
（３９）
　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
　前記保護部は、
　　前記第１通信を利用して第１セッション鍵を導出または受信し、
　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
　　前記第２セッション鍵を前記第２通信のメッセージ認証に使用し、
　　第１メッセージ認証ポリシーおよび第２メッセージ認証ポリシーのうち何れか一方を前記第２通信におけるメッセージ認証ポリシーとして選択し、
　　選択した前記メッセージ認証ポリシーに基づいてメッセージ認証を検証する
　移動体装置。
（４０）
　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
　前記保護部は、
　　前記第１通信を利用して第１セッション鍵を導出または受信し、
　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
　　前記第２セッション鍵を前記第２通信のメッセージ認証に使用し、
　　第１メッセージ認証ポリシーおよび第２メッセージ認証ポリシーのうち何れか一方を前記第２通信におけるメッセージ認証ポリシーとして選択し、
　　選択した前記メッセージ認証ポリシーに基づいてメッセージ認証を検証する
　通信システム。
（４１）
　前記保護部は、
　第１暗号データと第１乱数で構成された第１初期化ベクトルとを前記第２通信を使用して受信し、前記第２セッション鍵および前記第１初期化ベクトルを用いてＣＢＣモードで前記第１暗号データを前記復号するか否かの切り替えと、
　第２乱数で構成された第２初期化ベクトルを生成し、前記第２初期化ベクトルおよび前記第２セッション鍵を用いて前記ＣＢＣモードによる前記暗号化で第２暗号データを演算し、前記第２暗号データと前記第２初期化ベクトルとを前記第２通信を使用して送信するか否かの切り替えと、
　が可能に構成される
　（１）ないし（４０）のいずれか１つに記載の情報処理装置。
　なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
　本出願は、日本国特許庁において２０２１年２月９日に出願された日本特許出願番号第２０２１－０１８７６０号および２０２１年５月３１日に出願された日本特許出願番号第２０２１－０９１９３８号を基礎として優先権を主張するものであり、この出願のすべての内容を参照によって本出願に援用する。
　当業者であれば、設計上の要件や他の要因に応じて、種々の修正、コンビネーション、サブコンビネーション、および変更を想到し得るが、それらは添付の請求の範囲やその均等物の範囲に含まれるものであることが理解される。

Claims (20)

  1. 　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
    　前記保護部は、
    　　第１セッション鍵を導出または受信し、
    　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
    　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
    　　前記第２セッション鍵を前記第２通信の暗号化、復号またはメッセージ認証に使用し、
    　前記第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、前記第１デバイスと前記第３デバイスと間の第３通信と、前記第１通信とにおいて互いに異なる
    　情報処理装置。
  2. 　前記第１通信の通信経路は、前記第３通信の通信経路よりも長く、
    　前記総通信回数もしくは前記総通信データ量は、前記第３通信よりも前記第１通信において少ない
    　請求項１に記載の情報処理装置。
  3. 　前記保護部は、
    　前記第２通信を使用して、前記第２セッション鍵の使用開始タイミング指定を送信または受信し、
    　前記第３通信を使用して、前記使用開始タイミング指定または前記使用開始タイミング指定に関する情報を送信または受信する
    　請求項１に記載の情報処理装置。
  4. 　前記保護部は、前記第２通信を使用して、前記第２通信に関連する特異メッセージを送信または受信する
    　請求項１に記載の情報処理装置。
  5. 　請求項１に記載の情報処理装置。
  6. 　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵とは異なる乱数を送信または受信する
    　請求項１に記載の情報処理装置。
  7. 　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵の使用状況が確認される周期に関連する情報、または前記第２セッション鍵が更新される周期に関連する情報を送信または受信する
    　請求項１に記載の情報処理装置。
  8. 　前記保護部は、前記第１通信または前記第３通信において、前記第２通信のメッセージカウンタに関連する情報を送信または受信する
    　請求項１に記載の情報処理装置。
  9. 　前記保護部は、メッセージカウンタと前記メッセージカウンタに応じて変化する追加メッセージカウンタとを含み、
    　前記メッセージカウンタのカウント値と前記追加メッセージカウンタのカウント値とは、前記第２セッション鍵を使用する前記メッセージ認証によって保護されるメッセージの一部であり、
    　前記保護部は、前記第２通信において、前記メッセージカウンタのカウント値を送信または受信する
    　請求項１に記載の情報処理装置。
  10. 　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵の使用開始を要求するメッセージを送信または受信する
    　請求項１に記載の情報処理装置。
  11. 　前記保護部は、前記第１通信または前記第３通信において、前記第２セッション鍵の使用終了を要求するメッセージを送信または受信する
    　請求項１に記載の情報処理装置。
  12. 　前記第２通信の前記暗号化、復号またはメッセージ認証には、ＭＡＣモードを含む初期化ベクトルが用いられる
    　請求項１に記載の情報処理装置。
  13. 　前記保護部は、前記第２通信において、画像データおよび前記画像データに関連する埋め込みデータの送信または受信を行い、
    　前記埋め込みデータは、フレーム単位毎に変化するナンス情報の一部もしくは全部を含む
    　請求項１に記載の情報処理装置。
  14. 　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
    　前記保護部は、
    　　第１セッション鍵を導出または受信し、
    　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
    　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
    　　前記第２セッション鍵を前記第２通信の暗号化、復号またはメッセージ認証に使用し、
    　前記第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、前記第１デバイスと前記第３デバイスと間の第３通信と、前記第１通信とにおいて互いに異なる
    　移動体装置。
  15. 　第１デバイスと第２デバイスとの間の第１通信と、第３デバイスと前記第２デバイスとの間の第２通信とを保護する保護部を備え、
    　前記保護部は、
    　　第１セッション鍵を導出または受信し、
    　　前記第１セッション鍵を前記第１通信の暗号化もしくは復号とメッセージ認証とに使用し、
    　　前記第１セッション鍵によって保護された前記第１通信を使用して第２セッション鍵を受信し、
    　　前記第２セッション鍵を前記第２通信の暗号化、復号またはメッセージ認証に使用し、
    　前記第２セッション鍵の使用開始から使用終了までの間の総通信回数もしくは総通信データ量は、前記第１デバイスと前記第３デバイスと間の第３通信と、前記第１通信とにおいて互いに異なる
    　通信システム。
  16. 　前記第２セッション鍵を前記第２通信の前記メッセージ認証に使用し、
    　第１メッセージ認証ポリシーおよび第２メッセージ認証ポリシーのうち何れか一方を選択した前記第２通信におけるメッセージ認証ポリシーに基づいて前記第２通信の前記メッセージ認証を検証する
    　請求項１に記載の情報処理装置。
  17. 　前記保護部は、前記第１通信を介して送信または受信された情報に基づいて前記第２通信におけるメッセージ認証ポリシーを選択する
    　請求項１に記載の情報処理装置。
  18. 　前記保護部は、機能レジスタを含み、前記機能レジスタに格納される情報を、前記第１通信を介して送信または受信し、
    　前記機能レジスタには、前記第２通信の前記メッセージ認証に対して前記保護部が保持できるデータ量上限に関連する情報が格納され、
    　前記保護部は、前記データ量上限を超えない範囲内のデータ群に対して前記第２通信の前記メッセージ認証を検証する
    　請求項１に記載の情報処理装置。
  19. 　前記保護部は、前記第２通信を使用して、メッセージ群または拡張パケットヘッダの送信または受信を行い、
    　前記メッセージ群における最終メッセージまたは前記拡張パケットヘッダが、ＭＡＣ演算またはＣＲＣ演算を完了できるか否かを示す情報を含む
    　請求項１に記載の情報処理装置。
  20. 　前記保護部は、
    　第１暗号データと第１乱数で構成された第１初期化ベクトルとを前記第２通信を使用して受信し、前記第２セッション鍵および前記第１初期化ベクトルを用いてＣＢＣモードで前記第１暗号データを前記復号するか否かの切り替えと、
    　第２乱数で構成された第２初期化ベクトルを生成し、前記第２初期化ベクトルおよび前記第２セッション鍵を用いて前記ＣＢＣモードによる前記暗号化で第２暗号データを演算し、前記第２暗号データと前記第２初期化ベクトルとを前記第２通信を使用して送信するか否かの切り替えと、
    　が可能に構成される
    　請求項１に記載の情報処理装置。
PCT/JP2022/001450 2021-02-09 2022-01-17 情報処理装置、移動体装置、および通信システム WO2022172698A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022581276A JPWO2022172698A1 (ja) 2021-02-09 2022-01-17
US18/037,245 US20240007295A1 (en) 2021-02-09 2022-01-17 Information processor, mobile body apparatus, and communication system
CN202280013138.8A CN116803050A (zh) 2021-02-09 2022-01-17 信息处理设备、移动设备及通信系统

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2021018760 2021-02-09
JP2021-018760 2021-02-09
JP2021-091938 2021-05-31
JP2021091938 2021-05-31

Publications (1)

Publication Number Publication Date
WO2022172698A1 true WO2022172698A1 (ja) 2022-08-18

Family

ID=82837729

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/001450 WO2022172698A1 (ja) 2021-02-09 2022-01-17 情報処理装置、移動体装置、および通信システム

Country Status (3)

Country Link
US (1) US20240007295A1 (ja)
JP (1) JPWO2022172698A1 (ja)
WO (1) WO2022172698A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014182467A (ja) * 2013-03-18 2014-09-29 Dainippon Printing Co Ltd 情報記憶媒体、データ選択処理プログラム、及びデータ選択処理方法
WO2016075869A1 (ja) * 2014-11-13 2016-05-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 鍵管理方法、車載ネットワークシステム及び鍵管理装置
US20180109696A1 (en) * 2016-10-14 2018-04-19 Intel Corporation Transmission of Encrypted Image Data
JP2018182665A (ja) * 2017-04-20 2018-11-15 富士通株式会社 通信装置、通信システム及び暗号化通信制御方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014182467A (ja) * 2013-03-18 2014-09-29 Dainippon Printing Co Ltd 情報記憶媒体、データ選択処理プログラム、及びデータ選択処理方法
WO2016075869A1 (ja) * 2014-11-13 2016-05-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 鍵管理方法、車載ネットワークシステム及び鍵管理装置
US20180109696A1 (en) * 2016-10-14 2018-04-19 Intel Corporation Transmission of Encrypted Image Data
JP2018182665A (ja) * 2017-04-20 2018-11-15 富士通株式会社 通信装置、通信システム及び暗号化通信制御方法

Also Published As

Publication number Publication date
JPWO2022172698A1 (ja) 2022-08-18
US20240007295A1 (en) 2024-01-04

Similar Documents

Publication Publication Date Title
US11134100B2 (en) Network device and network system
US9596075B2 (en) Transparent serial encryption
ES2691258T3 (es) Sistema y método para una comunicación anfitrión-esclavo segura
US11086810B2 (en) Intelligent controller and sensor network bus, system and method including multi-layer platform security architecture
WO2017038500A1 (ja) 中継装置
US11156987B2 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
WO2022075081A1 (ja) 情報処理装置、移動体装置、および通信システム
WO2022050057A1 (ja) 情報処理装置、移動体装置、および通信システム
KR20200050384A (ko) 동기식 데이터 네트워크들을 통한 콘텐트 보호
EP3751781B1 (en) Overhead reduction for link protection
US20200089645A1 (en) Security techniques for a peripheral component interconnect (pci) express (pcie) system
US20230208825A1 (en) Method and Apparatus for Managing Reception of Secure Data Packets
JP2017121091A (ja) Ｅｃｕ、及び車用ネットワーク装置
WO2022113812A1 (ja) 情報処理装置、移動体装置、および通信システム
CN114270328A (zh) 智能控制器和传感器网络总线以及包括多层平台安全架构的系统和方法
WO2022172698A1 (ja) 情報処理装置、移動体装置、および通信システム
US11809163B2 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
CN116803050A (zh) 信息处理设备、移动设备及通信系统
JP6348150B2 (ja) 通信システム、通信制御装置及び不正情報送信防止方法
US11599649B2 (en) Method and apparatus for managing transmission of secure data packets
WO2021222641A1 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
WO2023243433A1 (ja) 情報処理装置、情報処理方法、プログラム、および通信システム
WO2023210325A1 (en) Transmission apparatus, transmission method, reception apparatus, reception method, program, and transmission system
WO2023223821A1 (ja) 送信装置、受信装置、情報処理方法、プログラム、および通信システム
KR101081773B1 (ko) 이더넷 ｌａｎ에서 프레임 보안을 위한 물리 계층 데이터 보안 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22752530

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18037245

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2022581276

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 202280013138.8

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22752530

Country of ref document: EP

Kind code of ref document: A1