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

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

Info

Publication number
JP7721553B2
JP7721553B2 JP2022555361A JP2022555361A JP7721553B2 JP 7721553 B2 JP7721553 B2 JP 7721553B2 JP 2022555361 A JP2022555361 A JP 2022555361A JP 2022555361 A JP2022555361 A JP 2022555361A JP 7721553 B2 JP7721553 B2 JP 7721553B2
Authority
JP
Japan
Prior art keywords
packet
extended
cci
phy
data
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2022555361A
Other languages
English (en)
Other versions
JPWO2022075081A5 (ja
JPWO2022075081A1 (ja
Inventor
宗 宮本
宏雄 高橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Semiconductor Solutions Corp
Original Assignee
Sony Semiconductor Solutions Corp
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 Sony Semiconductor Solutions Corp filed Critical Sony Semiconductor Solutions Corp
Publication of JPWO2022075081A1 publication Critical patent/JPWO2022075081A1/ja
Publication of JPWO2022075081A5 publication Critical patent/JPWO2022075081A5/ja
Application granted granted Critical
Publication of JP7721553B2 publication Critical patent/JP7721553B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0485—Networking architectures for enhanced packet encryption processing, e.g. offloading of IPsec packet processing or efficient security association look-up
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/385—Information transfer, e.g. on bus using universal interface adapter for adaptation of a particular data processing system to different peripheral devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4009—Coupling between buses with data restructuring
    • G06F13/4018—Coupling between buses with data restructuring with data-width conversion
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4027—Coupling between buses using bus bridges
    • G06F13/4045—Coupling between buses using bus bridges where the bus bridge performs an extender function
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/565—Static detection by checking file integrity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/0002—Inspection of images, e.g. flaw detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • 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
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23892—Multiplex stream processing, e.g. multiplex stream encrypting involving embedding information at multiplex stream level, e.g. embedding a watermark at packet level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/60—Control of cameras or camera modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N25/00—Circuitry of solid-state image sensors [SSIS]; Control thereof
    • H04N25/70—SSIS architectures; Circuits associated therewith
    • H04N25/71—Charge-coupled device [CCD] sensors; Charge-transfer registers specially adapted for CCD sensors
    • H04N25/75—Circuitry for providing, modifying or processing image signals from the pixel array
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/60—Control of cameras or camera modules
    • H04N23/66—Remote control of cameras or camera parts, e.g. by remote control devices
    • H04N23/663—Remote control of cameras or camera parts, e.g. by remote control devices for controlling interchangeable camera parts based on electronic image sensor signals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Virology (AREA)
  • Quality & Reliability (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Cardiology (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

本開示は、情報処理装置、移動体装置、および通信システムに関し、特に、より安全性を高めることができるようにした情報処理装置、移動体装置、および通信システムに関する。
現在、規格化が進行中であるCSI(Camera Serial Interface)-2 ver4.0では、物理層にC-PHYを使うパケット構造と、物理層にD-PHYを使うパケット構造との２種類が定義されている。
また近年、CSI-2規格は、モバイル機器だけに用いられるのではなく、車載やIoT（Internet of Things）など様々な用途に広く用いられるようになった結果、既存のパケット構造では、それらの用途に対応することができないと想定される。そこで、MIPI（Mobile Industry Processor Interface）アライアンスでは、多様な用途に対応させるため、既存のパケットヘッダやパケットフッタなどのパケット構造を拡張させた拡張パケットが検討中となっている。
例えば、特許文献１で開示されているように、従来のパケットヘッダとは別に、拡張されたパケットヘッダを利用する通信システムが提案されている。
国際公開第２０２０／１２９６８５号
ところで、上述したように検討中の拡張パケット内に格納される機能安全用途のメッセージカウント値は、セキュリティ用途のナンス値として流用されることができる。しかしながら、例えば、攻撃対策のために同じセッション鍵に対するナンス値はロールオーバー禁止とされているので、16bitのメッセージカウント値を、そのままナンス値として適用するのには適していない。そこで、具体的かつ、より安全性を高めてナンス値を使用できるようにすることが求められている。
本開示は、このような状況に鑑みてなされたものであり、より安全性を高めることができるようにするものである。
本開示の一側面の情報処理装置、移動体装置、および通信システムは、他の情報処理装置と通信を行って、画像データを含むフレームのデータを、自らと前記他の情報処理装置との間で所定の方向に送信する高速データ送信する際に、拡張パケットヘッダおよびパケットデータを含む拡張パケットと、前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとを前記他の情報処理装置に送信する、または、前記他の情報処理装置から受信する通信部と、セッション鍵を導出し、前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかを実行する保護部とを備え、前記画像データは、前記パケットデータ内に格納され、前記画像データおよび前記特異メッセージは、前記通信に係る共通の通信経路の一部または全部を介して、異なるタイミングで送信される情報処理装置、移動体装置、および通信システムである。
本開示の一側面においては、他の情報処理装置と通信が行われて、画像データを含むフレームのデータが、自らと前記他の情報処理装置との間で所定の方向に送信される高速データ送信がなされる際に、拡張パケットヘッダおよびパケットデータを含む拡張パケットと、前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとが前記他の情報処理装置に送信され、または、前記他の情報処理装置から受信され、セッション鍵が導出され、前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかが実行され、前記画像データが、前記パケットデータ内に格納され、前記画像データおよび前記特異メッセージが、前記通信に係る共通の通信経路の一部または全部を介して、異なるタイミングで送信される。
本技術を適用した通信システムの第１の実施の形態の構成例を示すブロック図である。 本技術を適用した通信システムの第２の実施の形態の構成例を示すブロック図である。 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応答メッセージの設定例を説明する図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜通信システムの構成例＞
図１は、本技術を適用した通信システムの第１の実施の形態の構成例を示すブロック図である。
図１に示すように、通信システム１１は、イメージセンサ２１およびアプリケーションプロセッサ２２がバス２３を介して接続されて構成される。例えば、通信システム１１は、いわゆるスマートフォンなどのような既存のモバイル機器の内部におけるCSI-2接続に用いられる。
イメージセンサ２１は、例えば、レンズや撮像素子（いずれも図示せず）などとともに、拡張モード対応CSI-2送信回路３１が組み込まれて構成される。例えば、イメージセンサ２１は、撮像素子が撮像することで取得した画像の画像データを、拡張モード対応CSI-2送信回路３１によりアプリケーションプロセッサ２２へ送信する。
アプリケーションプロセッサ２２は、通信システム１１を備えるモバイル機器で実行される各種のアプリケーションに応じた処理を行うLSI（Large Scale Integration）とともに、拡張モード対応CSI-2受信回路３２が組み込まれて構成される。例えば、アプリケーションプロセッサ２２は、イメージセンサ２１から送信されてくる画像データを、拡張モード対応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は、ポイントツーポイントトポロジの非対称データリンク層（非対称上位層）を有し、同一の物理配線を、高速データ伝送、制御データ、電力でシェアすることを可能としており、カメラ、センサ、ディスプレイの統合を簡素化するように設計されたエンドツーエンドシステムの基盤として機能すると同時に、機能的な安全性とセキュリティも組み込むことも可能としている。
このように構成される通信システム１１および１１Ａは、拡張モード対応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～0x3Fがリザーブと定義されている。そこで、D-PHY用の拡張パケットでは、既存ではリザーブとなっているデータタイプを利用して、受信側で拡張モードを識別するための設定情報が新たに定義される。
例えば、データタイプとして、・DataType[5:3]=3’b111の場合、拡張モード・DataType[2]=Reserve（RES：将来の拡張のための予約）・DataType[1:0]=extension mode type（４つの拡張モードを用意）を定義する。
即ち、既存のCSI-2規格ではリザーブと定義されているデータタイプの0x38～0x3Fのうち、例えば、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に適応することができるように、E2E protectionの保護範囲を、アプリケーションに特有のペイロードである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生成部３２１において分割されたAdaptation Layerを結合する処理を行う。
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、およびDestination Addressが格納される。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フッタを付加する。
このようなパケット構造のリードコマンドが、アプリケーションプロセッサ５１２のA-PHY処理部５３１によってA-PHY転送される。そして、イメージセンサ５１１では、A-PHY処理部５２１が、リードコマンドからA-PHYヘッダおよびA-PHYフッタを除去する。その後、リードコマンドは、Destination IDにより示されるスレーブアドレス「7'h0D」のCCI処理部５２５を介して、CCI-FS処理部５２６に供給される。
図３０には、リードアクセス時に、CCI-FS処理部５２６に供給されるリードコマンドと、CCI-FS処理部５２６において生成されるリードデータのパケット構造の一例が示されている。
図３０に示すように、図２８に示したパケット構造のままのリードコマンド、即ち、A-PHY転送において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、およびDestination Addressが格納される。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～Data 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の保護範囲を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計算結果とが一致したと判定された場合、処理はステップＳ２３４に進む。
ステップＳ２３４において、イメージセンサ５１１では、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処理部６５２、CCI-FS処理部６５３、レジスタ６５４、およびCCI-FSスイッチ６５５を備えて構成される。
なお、図４０に示すようなSerDes接続構成では、CCI構成やCCI-FS構成が上位プロトコルとして実装されている場合、他のSerDes規格を使用してもよい。例えば、Application Layer、または、その下のレイヤに相当する上位層からの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装置６１３のレジスタ６４７のレジスタアドレス（Register Address [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処理部６２３において生成されるリードデータのパケット構造の一例が示されている。
図４５に示すように、図４１に示したパケット構造のままのリードコマンド、即ち、A-PHY転送において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装置６１３のCCI-FS処理部６４３の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+W 8-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+W 8-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装置６１２が行う処理を例に説明するが、図５１のステップＳ３２２のSequence B（SerDes(Master)時）、図５１のステップＳ３２６のSequence B（Image Sensor時）処理、および、図５２のステップＳ３３２のSequence B（SerDes(Master)時）処理も同様に行われる。
ステップＳ３９１において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDを確認する。
ステップＳ３９２において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDとが不一致であるか否かを判定する。
ステップＳ３９２において、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDとが不一致であると判定された場合、処理はステップＳ３９３に進む。
ステップＳ３９３において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のDestination SIDと拡張パケットヘッダePHのDestination SIDを確認する。
ステップＳ３９４において、スレーブ側のSerDes装置６１２では、CCI-FS処理部６３６が、スレーブ側のSerDes装置６１２のSource IDと拡張パケットヘッダePHのDestination SIDとが一致したか否かを判定する。
ステップＳ３９４において、スレーブ側の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+W 8-bit）を発行する。
ステップＳ４１２において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したか否かを判定する。ステップＳ４１２において、マスタ側のSerDes装置６１３のI2C/I3Cスレーブ６４４からのACK応答を受信したと判定された場合、処理はステップＳ４１３に進む。
ステップＳ４１３において、アプリケーションプロセッサ６１４では、I2C/I3Cマスタ６５１が、スタートコマンドおよびスレーブアドレス（図４８に示したSlave Address+R 8-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処理部の回路構成の一例を示すブロック図である。図６５に示すCCI-FS処理部９０１およびレジスタ９０２は、上述した各デバイスが備える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装置）または目的とするデバイスに、事前設定または固有値のSource ID、事前設定された接続先情報を元にデータを転送し、目的とするデバイスへ向けてアクセスを行う。
イメージセンサ６１１の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に基づいて、コマンドの開始、再開、および終了情報が参照される。CCI Header 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ヘッダおよびA-PHYフッタを除去して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ヘッダおよびA-PHYフッタを除去して、拡張パケットヘッダePH*(*=n)、AP(CCI)ペイロード、拡張パケットフッタePF1、および拡張パケットフッタePF0を、CCI-FS処理部５３６に供給する。CCI-FS処理部５３６は、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（Galois MAC）、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～28ビット幅あれば十分である。もちろん、その限りではなく、それ以上のビット幅を用いてもよい。
例えば、給油式の車両であれば給油の際に電源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ビット幅の上位カウント値を併用すると(220-1)÷60≒5時間
・8ビット幅の上位カウント値を併用すると(224-1)÷60≒78時間
・12ビット幅の上位カウント値を併用すると(228-1)÷60≒52日
・16ビット幅の上位カウント値を併用すると(232-1)÷60≒828日
・20ビット幅の上位カウント値を併用すると(236-1)÷60≒36年
・24ビット幅の上位カウント値を併用すると(240-1)÷60≒581年となる。
ここで、イメージセンサ１２１１またはアプリケーションプロセッサ１２１２の電源が再起動（OFFの後にON）される場合、保護された画像データを再び送信する前に鍵交換が必要になるので、それに応じてセッション鍵は更新される。例えば、一般的な車載用途で、３日以上も電源を再起動しない可能性は低く、２年以上も電源を再起動しない可能性は極めて低いので、上位カウント値は8～16ビット幅あれば十分である。もちろん、その限りではなく、それ以上のビット幅を用いてもよい。
例えば、給油式の車両であれば給油の際に電源OFFとすればよく、給油式または充電式の車両であっても車両点検の際に電源OFFとすれば、保護された画像データを再び送信する前に鍵交換が必要になるので、それに応じてセッション鍵は更新される。例えば、IoT（Internet of ThingsまたはIntelligence of Things）向けイメージセンサが想定される場合、電源が再起動されないことも想定されるので、上位カウント値は20～24ビット幅あれば十分である。もちろん、その限りではなく、それ以上のビット幅を用いてもよい。
＜暗号化および復号＞
図９６乃至図１００を参照して、暗号化および復号について説明する。
図９６には、初期化ベクトルが格納される初期カウンタブロックの一例が示されている。
図９６に示すように、初期化ベクトルの構造を共通化する一方で、バーチャルチャネル間で異なる値とすることで、より簡単な実装を可能とすることができる。また、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 for future 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_RSP response 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、またはDisplay Streamなどの何れかのID（Stream ID）であってもよい。また、Video streamでなくAudio streamがストリームとして用いられてもよいため、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（Galois MAC）、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）などのうちの少なくとも何れかのstandards bodyが定義する規格内に適用されてもよいし、これらのうちの少なくとも何れかの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規格に準じるメッセージまたは他規格に準じるメッセージなどで定義されてもよい。
＜コンピュータの構成例＞
図１８２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
コンピュータにおいて、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２２０４にインストールしたり、更新したりすることができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
＜１＞ 他の情報処理装置と通信を行って、画像データを含むフレームのデータを、自らと前記他の情報処理装置との間で所定の方向に送信する高速データ送信する際に、
拡張パケットヘッダおよびパケットデータを含む拡張パケットと、
前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとを
前記他の情報処理装置に送信する、または、前記他の情報処理装置から受信する通信部と、
セッション鍵を導出し、前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかを実行する保護部とを備え、
前記画像データは、前記パケットデータ内に格納され、
前記画像データおよび前記特異メッセージは、前記通信に係る共通の通信経路の一部または全部を介して、異なるタイミングで送信される
情報処理装置。
＜２＞ 前記通信部は、前記高速データ送信に関連する前記所定の方向に対して逆方向の低速コマンド送信を送信または受信し、
前記高速データ送信は、前記低速コマンド送信と比較して高速であって、前記フレームが開始されることを示すフレームスタートの送信、および、前記フレームが終了されることを示すフレームエンドの送信が少なくとも行われ、
前記フレームは、複数個が連続的かつ周期的に送信可能であり、前記フレームエンドと次の前記フレームスタートとの間に前記画像データが送信されないフレームブランキングを含む
＜１＞に記載の情報処理装置。
＜３＞ 前記低速コマンド送信は、前記自らまたは前記他の情報処理装置に情報の書き込みを要求する書き込み命令、読み出しを要求する読み出し命令、または前記読み出し命令に応じた読み出し応答の送信を含み、
前記特異メッセージは、前記書き込み命令、前記読み出し命令、または前記読み出し応答として、前記フレームブランキング期間内に送信される
＜２＞に記載の情報処理装置。
＜４＞ 前記フレームは、前記フレームスタートと前記フレームエンドとの間の期間内に前記高速データ送信される埋込データを含み、
前記埋込データは、前記画像データに関連するメタデータを含み、
前記特異メッセージは、前記埋込データ内に格納されて送信される
＜２＞に記載の情報処理装置。
＜５＞ 前記低速コマンド送信は、前記自らまたは前記他の情報処理装置に情報の書き込みを要求する書き込み命令、読み出しを要求する読み出し命令、または前記読み出し命令に応じた読み出し応答の送信を含み、
前記フレームは、前記フレームスタートと前記フレームエンドとの間に前記画像データが送信されないラインブランキングを含み、
前記特異メッセージは、前記書き込み命令、前記読み出し命令、または前記読み出し応答として、前記ラインブランキングの期間内に送信される
＜２＞に記載の情報処理装置。
＜６＞ 前記特異メッセージは、前記フレームスタートの内部または前記フレームエンドの内部に格納されて送信される
＜２＞に記載の情報処理装置。
＜７＞ 前記フレームは、第１バーチャルチャネルである前記画像データとは異なる第２バーチャルチャネルのデータを含み、
前記特異メッセージは、前記第２バーチャルチャネルのデータ内に格納されて送信される
＜１＞乃至＜６＞のいずれかに記載の情報処理装置。
＜８＞ 前記拡張パケットは、拡張パケットフッタをさらに含み、
前記特異メッセージは、前記画像データが格納される拡張パケット内の拡張パケットヘッダ内に格納され、
前記保護データは、前記画像データが格納される拡張パケット内の拡張パケットフッタ内に格納されて送信される
＜１＞乃至＜７＞のいずれかに記載の情報処理装置。
＜９＞ 前記通信部は、
HEARTBEAT要求または疑似HEARTBEAT要求の送信または受信と、
前記HEARTBEAT要求または前記疑似HEARTBEAT要求に応じた所定時間内のHEARTBEAT_ACK応答または疑似HEARTBEAT_ACK応答の受信または送信とを含み、
前記自らまたは前記他の情報処理装置は、必要に応じて、前記所定時間内に、前記特異メッセージを前記通信の相手に送信する
＜１＞乃至＜８＞のいずれかに記載の情報処理装置。
＜１０＞ 前記通信部は、
HEARTBEAT要求または疑似HEARTBEAT要求の送信または受信と、
前記HEARTBEAT要求または前記疑似HEARTBEAT要求に応じた所定時間内のHEARTBEAT_ACK応答または疑似HEARTBEAT_ACK応答の受信または送信とを含み、
前記HEARTBEAT要求または前記疑似HEARTBEAT要求が正常に受信されない場合、前記高速データ送信を停止せず、前記HEARTBEAT_ACK応答または前記疑似HEARTBEAT_ACK応答の送信を停止する
＜１＞乃至＜８＞のいずれかに記載の情報処理装置。
＜１１＞ 前記HEARTBEAT要求および前記HEARTBEAT_ACK応答に非対応することを示すビットフラグが前記自らおよび前記他の情報処理装置の少なくともいずれかに設定され、
前記通信部は、
前記疑似HEARTBEAT要求の送信または受信と、
前記疑似HEARTBEAT要求に応じた所定時間内の前記疑似HEARTBEAT_ACK応答の受信または送信とを含む
＜１０＞に記載の情報処理装置。
＜１２＞ 前記画像データを撮像または表示する画素と、
前記画素または前記画像データに対する妨害の有無または前記妨害の可能性を検出する妨害検出部をさらに含み、
前記特異メッセージは、前記妨害検出部の検出結果に関連するメッセージである
＜１＞乃至＜１１＞のいずれかに記載の情報処理装置。
＜１３＞ 前記通信経路に対する障害の有無または前記障害の可能性を検出する障害検出部をさらに備え、
前記特異メッセージは、前記障害検出部の検出結果に関連するメッセージである
＜１＞乃至＜１２＞のいずれかに記載の情報処理装置。
＜１４＞ 前記保護部に対する侵害の有無または前記侵害の可能性を検出する侵害検出部をさらに含み、
前記特異メッセージは、前記侵害検出部の検出結果に関連するメッセージである
＜１＞乃至＜１３＞のいずれかに記載の情報処理装置。
＜１５＞ 前記自らの内部温度を検出する温度検出部をさらに含み、
前記特異メッセージは、前記温度検出部の検出結果に関連するメッセージである
＜１＞乃至＜１４＞のいずれかに記載の情報処理装置。
＜１６＞ 前記高速データ送信は、前記特異メッセージが所定停止条件を満たした後に、前記自らにより停止される
＜１＞乃至＜１５＞のいずれかに記載の情報処理装置。
＜１７＞ 前記自らおよび前記他の情報処理装置は、前記画像データを用いて直接的または間接的に必要に応じて推進を制御する推進部を備えた推進装置の一部であり、
前記高速データ送信は、前記推進装置が所定の停止条件を満たした後に、前記推進装置により停止される
＜１＞乃至＜１６＞のいずれかに記載の情報処理装置。
＜１８＞ 前記自らおよび前記他の情報処理装置は、前記画像データを用いて直接的または間接的に必要に応じて推進を制御する推進部を備えた推進装置の一部であり、
前記推進装置は、前記画像データとは異なる他のデータを取得または表示する処理構成を備え、
前記特異メッセージが受信された場合、前記推進部は、前記画像データよりも前記他のデータを優先して用いて推進を制御する
＜１＞乃至＜１７＞のいずれかに記載の情報処理装置。
＜１９＞ 他の情報処理装置と通信を行って、画像データを含むフレームのデータを、自らと前記他の情報処理装置との間で所定の方向に送信する高速データ送信する際に、
拡張パケットヘッダおよびパケットデータを含む拡張パケットと、
前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとを
前記他の情報処理装置に送信する、または、前記他の情報処理装置から受信する通信部と、
セッション鍵を導出し、前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかを実行する保護部とを備え、
前記画像データは、前記パケットデータ内に格納され、
前記画像データおよび前記特異メッセージは、前記通信に係る共通の通信経路の一部または全部を介して、異なるタイミングで送信される
情報処理装置を備える移動体装置。
＜２０＞ 他の情報処理装置と通信を行って、画像データを含むフレームのデータを、自らと前記他の情報処理装置との間で所定の方向に送信する高速データ送信する際に、
拡張パケットヘッダおよびパケットデータを含む拡張パケットと、
前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとを
前記他の情報処理装置に送信する、または、前記他の情報処理装置から受信する通信部と、
セッション鍵を導出し、前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかを実行する保護部とを備え、
前記画像データは、前記パケットデータ内に格納され、
前記画像データおよび前記特異メッセージは、前記通信に係る共通の通信経路の一部または全部を介して、異なるタイミングで送信される
情報処理装置を備える通信システム。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
１２０１ 通信システム， １２１１ イメージセンサ， １２１２ アプリケーションプロセッサ， １２１３ ディスプレイ， １３０１ 画素， １３０２ AD変換器， １３０３ 画像処理部， １３０４ 拡張モード対応CSI-2送信回路， １３０５ 物理層処理部， １３０６ I2C/I3Cスレーブ， １３０７ 記憶部， １３０８ メッセージカウンタ， １３０９ ナンス更新部， １３１０ セキュリティ部， １３２１ 物理層処理部， １３２２ 拡張モード対応CSI-2受信回路， １３２３ I2C/I3Cマスタ， １３２４ 記憶部， １３２５ データ検証部， １３２６ セキュリティ部， １３２７ コントローラ， １５０１ 画素， １５０２ AD変換器， １５０３ 画像処理部， １５０４ 拡張モード対応CSI-2送信回路， １５０５ 物理層処理部， １５０６ I2C/I3Cスレーブ， １５０７ 記憶部， １５０８ 妨害検出部， １５０９ 障害検出部， １５１０ セキュリティ部， １５１１ 侵害検出部， １５１２ 温度検出部， １５１３ メッセージカウンタ， １５５１ 物理層処理部， １５５２ 拡張モード対応CSI-2受信回路， １５５３ I2C/I3Cマスタ， １５５４ 記憶部， １５５５ コントローラ， １５５６ 妨害検出部， １５５７ 障害検出部， １５５８ セキュリティ部， １５５９ 侵害検出部， １５６０ 温度検出部

Claims (20)

  1. 他の情報処理装置と通信を行って、画像データを含むフレームのデータを、自らと前記他の情報処理装置との間で所定の方向に送信するデータ通信する際に、
    パケットヘッダおよびパケットデータを含むパケットと、
    前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとを
    前記他の情報処理装置に送信する、または、前記他の情報処理装置から受信する通信部と、
    セッション鍵を用いて前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかを実行する保護部とを備え、
    前記画像データは、前記パケットデータ内に格納され、
    前記画像データおよび前記特異メッセージは、異なるタイミングで送信または受信される
    情報処理装置。
  2. 前記パケットは、拡張パケットであり、
    前記パケットヘッダは、拡張パケットヘッダである
    請求項１に記載の情報処理装置。
  3. 前記通信部は、前記データ通信に関連するコマンドまたは前記コマンドに応じた応答を前記他の情報処理装置に送信または前記他の情報処理装置から受信するコマンド通信を行い、
    前記データ通信は、前記フレームが開始されることを示すフレームスタートの送信または受信、および、前記フレームが終了されることを示すフレームエンドの送信または受信を含み、
    前記フレームは、周期的に送信可能または受信可能であり、
    前記コマンド通信は、前記自らまたは前記他の情報処理装置に情報の書き込みを要求する書き込み命令、読み出しを要求する読み出し命令、または前記読み出し命令に応じた読み出し応答の送信または受信を含み、
    前記特異メッセージは、前記書き込み命令、前記読み出し命令、または前記読み出し応答として、前記フレームエンドと次の前記フレームスタートとの間の期間内に送信または受信される
    請求項１に記載の情報処理装置
  4. 前記フレームは、前記パケットデータ内に格納される埋込データを含み、
    前記埋込データは、前記画像データを表す属性または前記画像データに関連する情報を含み、
    前記特異メッセージは、前記埋込データ内に格納されて送信または受信される
    請求項１に記載の情報処理装置。
  5. 前記通信部は、前記データ通信に関連するコマンドまたは前記コマンドに応じた応答を前記他の情報処理装置に送信または前記他の情報処理装置から受信するコマンド通信を行い、
    前記データ通信は、前記フレームが開始されることを示すフレームスタートの送信または受信、および、前記フレームが終了されることを示すフレームエンドの送信または受信を含み、
    前記コマンド通信は、前記自らまたは前記他の情報処理装置に情報の書き込みを要求する書き込み命令、読み出しを要求する読み出し命令、または前記読み出し命令に応じた読み出し応答の送信または受信を含み、
    前記特異メッセージは、前記書き込み命令、前記読み出し命令、または前記読み出し応答として、前記フレームスタートと前記フレームエンドとの間の期間内に送信または受信される
    請求項１に記載の情報処理装置。
  6. 前記パケットは、拡張パケットであり、
    前記パケットヘッダは、拡張パケットヘッダであり、
    前記特異メッセージは、前記拡張パケットヘッダ内または前記パケットデータ内に格納される
    請求項１に記載の情報処理装置。
  7. 前記フレームは、前記パケットデータ内に格納される、非画像データを含み、
    前記特異メッセージは、前記非画像データ内に格納されて送信または受信される
    請求項１に記載の情報処理装置。
  8. 前記パケットは、拡張パケットであり、
    前記パケットヘッダは、拡張パケットヘッダであり、
    前記拡張パケットは、拡張パケットフッタをさらに含み、
    前記保護データは、前記拡張パケットフッタ内に格納されて送信または受信される
    請求項１に記載の情報処理装置。
  9. 前記通信部は、
    ＨＥＡＲＴＢＥＡＴ要求または疑似ＨＥＡＲＴＢＥＡＴ要求の送信または受信と、
    前記ＨＥＡＲＴＢＥＡＴ要求または前記疑似ＨＥＡＲＴＢＥＡＴ要求に応じた所定時間内のＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答または疑似ＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答の受信または送信とを行い、
    前記自らまたは前記他の情報処理装置は、必要に応じて、前記所定時間内に、前記特異メッセージを前記通信の相手に送信する
    請求項１に記載の情報処理装置。
  10. 前記通信部は、
    ＨＥＡＲＴＢＥＡＴ要求または疑似ＨＥＡＲＴＢＥＡＴ要求の送信または受信と、
    前記ＨＥＡＲＴＢＥＡＴ要求または前記疑似ＨＥＡＲＴＢＥＡＴ要求に応じた所定時間内のＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答または疑似ＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答の受信または送信とを行い、
    前記自らまたは前記他の情報処理装置は、前記ＨＥＡＲＴＢＥＡＴ要求または前記疑似ＨＥＡＲＴＢＥＡＴ要求が正常に受信されない場合、前記ＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答または前記疑似ＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答の送信を停止する
    請求項１に記載の情報処理装置。
  11. 前記通信部は、
    疑似ＨＥＡＲＴＢＥＡＴ要求の送信または受信と、
    前記疑似ＨＥＡＲＴＢＥＡＴ要求に応じた所定時間内の疑似ＨＥＡＲＴＢＥＡＴ＿ＡＣＫ応答の受信または送信とを行う
    請求項１に記載の情報処理装置。
  12. 前記画像データを撮像または表示する画素と、
    前記画素または前記画像データに対する妨害の有無または前記妨害の可能性を検出する妨害検出部をさらに含む
    請求項１に記載の情報処理装置。
  13. 前記通信に係る通信経路に対する障害の有無または前記障害の可能性を検出する障害検出部をさらに含む
    請求項１に記載の情報処理装置。
  14. 前記保護部に対する侵害の有無または前記侵害の可能性を検出する侵害検出部をさらに含む
    請求項１に記載の情報処理装置。
  15. 前記自らの内部温度を検出する温度検出部をさらに含む
    請求項１に記載の情報処理装置。
  16. 前記データ通信は、前記特異メッセージが所定停止条件を満たした後に停止される
    請求項１に記載の情報処理装置。
  17. 前記自らおよび前記他の情報処理装置は、前記画像データを用いて直接的または間接的に必要に応じて推進を制御する推進部を備えた推進装置の一部であり、
    前記データ通信は、前記推進装置が所定の停止条件を満たした後に停止される
    請求項１に記載の情報処理装置。
  18. 前記自らおよび前記他の情報処理装置は、前記画像データを用いて直接的または間接的に必要に応じて推進を制御する推進部を備えた推進装置の一部であり、
    前記推進装置は、前記画像データとは異なる他のデータを取得または表示する処理構成を備え、
    前記特異メッセージが受信された場合、前記推進部は、前記画像データよりも前記他のデータを優先して用いて推進を制御する
    請求項１に記載の情報処理装置。
  19. 他の情報処理装置と通信を行って、画像データを含むフレームのデータを、自らと前記他の情報処理装置との間で所定の方向に送信するデータ通信する際に、
    パケットヘッダおよびパケットデータを含むパケットと、
    前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとを
    前記他の情報処理装置に送信する、または、前記他の情報処理装置から受信する通信部と、
    セッション鍵を用いて前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかを実行する保護部と
    を備え、
    前記画像データは、前記パケットデータ内に格納され、
    前記画像データおよび前記特異メッセージは、異なるタイミングで送信または受信される
    情報処理装置を備える移動体装置。
  20. 他の情報処理装置と通信を行って、画像データを含むフレームのデータを、自らと前記他の情報処理装置との間で所定の方向に送信するデータ通信する際に、
    パケットヘッダおよびパケットデータを含むパケットと、
    前記自ら、前記他の情報処理装置、および前記画像データの少なくともいずれかが正常時または通常時とは異なる状態であることを通知可能な特異メッセージとを
    前記他の情報処理装置に送信する、または、前記他の情報処理装置から受信する通信部と、
    セッション鍵を用いて前記特異メッセージの保護データの生成、検証、および復号の少なくともいずれかを実行する保護部と
    を備え、
    前記画像データは、前記パケットデータ内に格納され、
    前記画像データおよび前記特異メッセージは、異なるタイミングで送信または受信される
    情報処理装置を備える通信システム。
JP2022555361A 2020-10-09 2021-09-24 情報処理装置、移動体装置、および通信システム Active JP7721553B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2020170968 2020-10-09
JP2020170968 2020-10-09
PCT/JP2021/034953 WO2022075081A1 (ja) 2020-10-09 2021-09-24 情報処理装置、移動体装置、および通信システム

Publications (3)

Publication Number Publication Date
JPWO2022075081A1 JPWO2022075081A1 (ja) 2022-04-14
JPWO2022075081A5 JPWO2022075081A5 (ja) 2023-06-26
JP7721553B2 true JP7721553B2 (ja) 2025-08-12

Family

ID=81126736

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022555361A Active JP7721553B2 (ja) 2020-10-09 2021-09-24 情報処理装置、移動体装置、および通信システム

Country Status (7)

Country Link
US (1) US12407661B2 (ja)
EP (1) EP4227817A4 (ja)
JP (1) JP7721553B2 (ja)
KR (1) KR20230084198A (ja)
CN (1) CN116235461A (ja)
TW (1) TWI894369B (ja)
WO (1) WO2022075081A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7639379B2 (ja) * 2021-02-10 2025-03-05 セイコーエプソン株式会社 回路装置、電子機器及び画像処理方法
JP2023163310A (ja) * 2022-04-28 2023-11-10 ソニーセミコンダクタソリューションズ株式会社 送信装置、送信方法、受信装置、受信方法、プログラム、および伝送システム
DE102022111513A1 (de) * 2022-05-09 2023-11-09 Vega Grieshaber Kg Füllstandsensor zum Aktivieren und Deaktivieren eines sicheren Betriebszustands
US12387021B2 (en) * 2022-06-07 2025-08-12 Cycuity, Inc. Using information flow for security aware design and analysis
DE102022125946A1 (de) * 2022-10-07 2024-04-18 Dspace Gmbh Selbstkonfigurierende Aufzeichnungsvorrichtung für Bilddaten von einer bildgebenden Sensorvorrichtung
CN116051518B (zh) * 2023-01-19 2024-03-26 中国电子产品可靠性与环境试验研究所（（工业和信息化部电子第五研究所）（中国赛宝实验室）） 木马位置定位方法、装置、计算机设备和存储介质
US12397712B2 (en) 2023-01-19 2025-08-26 Panasonic Automotive Systems Co., Ltd. Vehicular camera
JP7751360B2 (ja) * 2023-03-28 2025-10-08 パナソニックオートモーティブシステムズ株式会社 車載用カメラ
JP7714276B2 (ja) * 2023-01-19 2025-07-29 パナソニックオートモーティブシステムズ株式会社 車載カメラ
TWI845154B (zh) * 2023-02-09 2024-06-11 大陸商北京集創北方科技股份有限公司 數據傳輸電路、電子晶片及資訊處理裝置
CN117424606B (zh) * 2023-12-18 2024-04-16 成都行芯科技有限公司 波形数据压缩方法、装置、电子装置和存储介质
KR102712015B1 (ko) * 2024-01-03 2024-09-30 주식회사 메타씨앤아이 디스플레이 장치에 사용되는 직렬 인터페이스 회로 장치 및 이를 제어하는 방법
US20260039726A1 (en) * 2024-08-05 2026-02-05 Qualcomm Incorporated Resilient camera service extension (cse) design for advanced driver assistance systems (adas) applications

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006276093A (ja) 2005-03-28 2006-10-12 Hitachi Ltd Ｓｉｐメッセージの暗号化方法，および暗号化ｓｉｐ通信システム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3632167B2 (ja) * 1998-01-30 2005-03-23 株式会社日立製作所 暗号通信装置
JP4690600B2 (ja) * 2001-08-23 2011-06-01 富士通株式会社 データ保護方法
JP2004064181A (ja) * 2002-07-25 2004-02-26 Sanyo Electric Co Ltd ホームゲートウェイ装置およびプログラム
CN1925386A (zh) * 2006-09-30 2007-03-07 杭州华为三康技术有限公司 时钟同步方法以及应用该方法的第一部件和第二部件
JP4997323B2 (ja) * 2010-08-20 2012-08-08 株式会社三共 遊技機
US10015144B2 (en) * 2013-01-31 2018-07-03 Schedule1 Inc. Method and system for protecting data using data passports
WO2017209221A1 (ja) 2016-05-31 2017-12-07 ソニーセミコンダクタソリューションズ株式会社 撮像装置および撮像方法、カメラモジュール、並びに電子機器
US20190178961A1 (en) 2016-07-27 2019-06-13 Nippon Steel & Sumitomo Metal Corporation Bulk magnet structure, magnet system for nmr using said bulk magnetic structure and magnetization method for bulk magnet structure
JP6938327B2 (ja) 2017-01-25 2021-09-22 キヤノン株式会社 固体撮像装置、撮像システム及び移動体
KR102387461B1 (ko) 2017-07-24 2022-04-15 삼성전자주식회사 스토리지 장치, 스토리지 시스템 및 이의 동작 방법
US11039092B2 (en) 2017-11-15 2021-06-15 Nvidia Corporation Sparse scanout for image sensors
TWI868088B (zh) * 2018-12-20 2025-01-01 日商索尼半導體解決方案公司 通信裝置、通信方法及程式
CN110445809B (zh) * 2019-09-03 2022-02-25 深圳绿米联创科技有限公司 网络攻击检测方法、装置、系统、电子设备及存储介质

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006276093A (ja) 2005-03-28 2006-10-12 Hitachi Ltd Ｓｉｐメッセージの暗号化方法，および暗号化ｓｉｐ通信システム

Also Published As

Publication number Publication date
CN116235461A (zh) 2023-06-06
WO2022075081A1 (ja) 2022-04-14
US12407661B2 (en) 2025-09-02
TW202220408A (zh) 2022-05-16
TWI894369B (zh) 2025-08-21
US20230412575A1 (en) 2023-12-21
EP4227817A1 (en) 2023-08-16
JPWO2022075081A1 (ja) 2022-04-14
KR20230084198A (ko) 2023-06-12
EP4227817A4 (en) 2024-03-20

Similar Documents

Publication Publication Date Title
JP7721553B2 (ja) 情報処理装置、移動体装置、および通信システム
JP7785688B2 (ja) 情報処理装置、移動体装置、および通信システム
JP7793558B2 (ja) 情報処理装置、移動体装置、および通信システム
JP7679388B2 (ja) 情報処理装置、移動体装置、および通信システム
US12432187B2 (en) Secure stream protocol for serial interconnect
JP6126980B2 (ja) ネットワーク装置およびネットワークシステム
US10755156B2 (en) Configurable integrity protected link for secure accelerator communication
US11156987B2 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
US11086810B2 (en) Intelligent controller and sensor network bus, system and method including multi-layer platform security architecture
US11294846B2 (en) System, apparatus and method for secure communication on a bus
JP2014236248A (ja) 電子制御装置、電子制御システム
US12052231B2 (en) Method and apparatus for managing reception of secure data packets
US20220011749A1 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
JP2017121091A (ja) Ｅｃｕ、及び車用ネットワーク装置
JP2023182527A (ja) イメージデータを処理する制御器、及びそれを含むイメージ処理システム、並びにその動作方法
WO2021146174A1 (en) Intelligent controller and sensor network bus, system and method including multi-layer platform security architecture
CN116803050A (zh) 信息处理设备、移动设备及通信系统
WO2021222641A1 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
WO2023119893A1 (ja) データ処理装置
JP5940013B2 (ja) 車載通信システム及び通信装置
CN120934779A (zh) 通信设备和安全通信方法
KR20230171840A (ko) 이미지 데이터를 처리하는 제어기, 및 그것을 포함하는 이미지 처리 시스템 및 그것의 동작 방법

Legal Events

Date Code Title Description
A524 Written submission of copy of amendment under article 19 pct

Free format text: JAPANESE INTERMEDIATE CODE: A527

Effective date: 20230301

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240731

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20250701

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20250730

R150 Certificate of patent or registration of utility model

Ref document number: 7721553

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150