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

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

Info

Publication number
JP7679388B2
JP7679388B2 JP2022546215A JP2022546215A JP7679388B2 JP 7679388 B2 JP7679388 B2 JP 7679388B2 JP 2022546215 A JP2022546215 A JP 2022546215A JP 2022546215 A JP2022546215 A JP 2022546215A JP 7679388 B2 JP7679388 B2 JP 7679388B2
Authority
JP
Japan
Prior art keywords
packet
extended
data
cci
phy
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
JP2022546215A
Other languages
English (en)
Other versions
JPWO2022050057A5 (ja
JPWO2022050057A1 (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 JPWO2022050057A1 publication Critical patent/JPWO2022050057A1/ja
Publication of JPWO2022050057A5 publication Critical patent/JPWO2022050057A5/ja
Application granted granted Critical
Publication of JP7679388B2 publication Critical patent/JP7679388B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • 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
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • 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/36—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols with means for detecting characters not meant for transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00095—Systems or arrangements for the transmission of the picture signal
    • H04N1/00103—Systems or arrangements for the transmission of the picture signal specially adapted for radio transmission, e.g. via satellites
    • H04N1/00106—Systems or arrangements for the transmission of the picture signal specially adapted for radio transmission, e.g. via satellites using land mobile radio networks, e.g. mobile telephone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Astronomy & Astrophysics (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の一例を示す図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜通信システムの構成例＞
図１は、本技術を適用した通信システムの第１の実施の形態の構成例を示すブロック図である。
図１に示すように、通信システム１１は、イメージセンサ２１およびアプリケーションプロセッサ２２がバス２３を介して接続されて構成される。例えば、通信システム１１は、いわゆるスマートフォンなどのような既存のモバイル機器の内部における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エラーが検出された場合、その旨を示すcrcエラー検出信号を後段の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に適応したパケット送受信処理を説明するフローチャートである。
例えば、パケットデータに格納するデータ（例えば、画像データなど）が拡張モード対応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）は等価なものとする。
図６３は、上述の図２７に示した通信システム５０１と同様ように、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）の少なくとも一部内へ格納されて送信されてもよい。つまり、それらは非画像データ内に格納されてもよい。
なお、以上の説明では、撮像開始を明記しているが、撮像終了について明記してない。これは撮像方式がグローバルシャッタ方式なのかローリングシャッタ方式なのか等によって異なるためである。例えば、グローバルシャッタ方式であれば、全画素を一斉に撮像できるので、次処理の前までに撮像終了してもよいし、フレーム内の最初の画像データを送信する前までに撮像終了してもよい。一方、ローリングシャッタ方式であれば、画素の各行で実行される撮像および高速データ送信の少なくとも一部が重複して実行（並列実行）されてもよいため、フレーム内の最後の画像データを送信する前までに撮像終了すればよい。また、撮像開始の位置は一例であり、フレーム内の最初の画像データを送信する前の位置まで遅らせて実行されてもよい。
＜コンピュータの構成例＞
図１１８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
コンピュータにおいて、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２２０４にインストールしたり、更新したりすることができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
他の情報処理装置と通信を行って、画像データを含むフレームのデータを高速データ送信する際に、拡張パケットヘッダおよびパケットデータを含む拡張パケットを前記他の情報処理装置に送信する通信部と、
セッション鍵を導出し、前記セッション鍵を用いて前記パケットデータの第１保護データを生成する第１保護部と、
前記第１保護データを生成するたびに前記セッション鍵へ対してのナンス値を更新するナンス更新部と
を備え、
前記画像データは、前記パケットデータ内に格納され、
前記高速データ送信は、前記ナンス値の一部または全部の送信を含み、
前記ナンス値の一部または全部は、前記拡張パケットヘッダ外に格納されて送信される
情報処理装置。
（２）
前記通信部は、前記高速データ送信に関連するコマンドが前記他の情報処理装置から送信されてくる低速コマンド送信で、前記高速データ送信の開始を要求する高速データ送信開始命令を受信し、
前記高速データ送信は、前記低速コマンド送信と比較して高速であって、前記高速データ送信開始命令の受信に応じて開始され、前記フレームが開始されることを示すフレームスタートの送信、および、前記フレームが終了されることを示すフレームエンドの送信が少なくとも行われ、
前記フレームは、複数個が連続的かつ周期的に送信されることが可能であり、前記フレームエンドと次の前記フレームスタートとの間に前記画像データが送信されないフレームブランキングを含む
上記（１）に記載の情報処理装置。
（３）
前記低速コマンド送信は、前記情報処理装置内の情報を前記プロセッサへ読み出すことを要求する読み出し命令の送信を含み、
前記ナンス値の一部または全部は、前記読み出し命令に応じた読み出し応答として、前記フレームブランキングの期間内に送信される
上記（２）に記載の情報処理装置。
（４）
前記フレームは、前記フレームスタートと前記フレームエンドとの間の期間内に前記高速データ送信される埋込データを含み、
前記埋込データは、前記画像データに関連するメタデータを含み、
前記ナンス値の一部または全部は、前記埋込データ内に格納されて送信される
上記（２）または（３）に記載の情報処理装置。
（５）
前記低速コマンド送信は、前記情報処理装置内の情報を前記プロセッサへ読み出すことを要求する読み出し命令の送信を含み、
前記フレームは、前記フレームスタートと前記フレームエンドとの間に前記画像データが送信されないラインブランキングを含み、
前記ナンス値の一部または全部は、前記読み出し命令に応じた読み出し応答として、前記ラインブランキングの期間内に送信される
上記（２）から（４）までのいずれかに記載の情報処理装置。
（６）
前記フレームは、第１バーチャルチャネルである前記画像データとは異なる第２バーチャルチャネルのデータを含み、
前記ナンス値の一部または全部は、前記第２バーチャルチャネルのデータ内に格納されて送信される
上記（１）から（５）までのいずれかに記載の情報処理装置。
（７）
前記ナンス値の一部の残りの一部または全部は、前記拡張パケットヘッダ内に格納されて送信される
上記（１）から（６）までのいずれかに記載の情報処理装置。
（８）
前記高速データ送信は、前記フレームが開始されることを示すフレームスタートの送信、および、前記フレームが終了されることを示すフレームエンドの送信を含み、
前記ナンス値の一部または全部は、前記フレームスタート内またはフレームエンド内に格納されて送信される
上記（１）から（７）までのいずれかに記載の情報処理装置。
（９）
前記ナンス値の一部または全部は、前記第１保護データを演算する際の初期化ベクトルの一部として用いられ、
前記初期化ベクトルは、前記通信の拡張仮想チャネルに関連する情報を含む
上記（１）から（８）までのいずれかに記載の情報処理装置。
（１０）
前記ナンス値の一部または全部は、前記第１保護データを演算する際の初期化ベクトルの一部として用いられ、
前記初期化ベクトルは、前記通信の拡張データタイプに関連する情報を含む
上記（１）から（９）までのいずれかに記載の情報処理装置。
（１１）
前記ナンス値の一部または全部は、前記第１保護データを演算する際の初期化ベクトルの一部として用いられ、
前記初期化ベクトルは、前記通信のSPDM（Security Protocol and Data Model）セッションIDに関連する情報を含む
上記（１）から（１０）までのいずれかに記載の情報処理装置。
（１２）
前記ナンス値の一部または全部は、前記第１保護データを演算する際の初期化ベクトルの一部として用いられ、
前記初期化ベクトルは、SPDMまたはHDCP（High-bandwidth Digital Content Protection）を識別する情報を含む
上記（１）から（１１）までのいずれかに記載の情報処理装置。
（１３）
前記ナンス値の一部または全部は、前記第１保護データを演算する際の初期化ベクトルの一部として用いられ、
前記初期化ベクトルは、前記通信のソースIDに関連する情報を含む
上記（１）から（１２）までのいずれかに記載の情報処理装置。
（１４）
前記ナンス値の一部または全部は、前記第１保護データを演算する際の初期化ベクトルの一部として用いられ、
前記初期化ベクトルは、前記通信の最終目的地IDに関連する情報を含む
上記（１）から（１３）までのいずれかに記載の情報処理装置。
（１５）
所定カウント条件を満たす拡張パケットを送信するたびにメッセージカウント値を更新するメッセージカウンタをさらに備え、
前記メッセージカウント値は、前記拡張パケットヘッダ内に格納され、
前記ナンス値および前記メッセージカウント値は、更新が同期される
上記（１）から（１４）までのいずれかに記載の情報処理装置。
（１６）
所定カウント条件を満たす拡張パケットを送信するたびにメッセージカウント値を更新するメッセージカウンタをさらに備え、
前記メッセージカウント値は、前記拡張パケットヘッダ内に格納され、
前記ナンス更新部と前記メッセージカウンタとは、別体であり、前記ナンス値と前記メッセージカウント値とは、更新が非同期である
上記（１）から（１５）までのいずれかに記載の情報処理装置。
（１７）
前記拡張パケットは、拡張パケットフッタを含み、前記第１保護部は、前記セッション鍵を用いて完全性演算値を生成し、
前記完全性演算値は、少なくとも前記パケットデータを保護し、前記拡張パケットフッタ内に格納される
上記（１）から（１６）までのいずれかに記載の情報処理装置。
（１８）
前記第１保護部は、前記セッション鍵を用いて完全性演算値を生成し、
前記完全性演算値は、少なくとも前記画像データを保護し、前記画像データとは異なるパケットデータ内に格納される
上記（１）から（１７）までのいずれかに記載の情報処理装置。
（１９）
画像データを出力する画素と、
他の情報処理装置と通信を行って、前記画像データを含むフレームのデータを高速データ送信する際に、拡張パケットヘッダおよびパケットデータを含む拡張パケットを前記他の情報処理装置に送信する通信部と、
セッション鍵を導出し、前記セッション鍵を用いて前記パケットデータの第１保護データを生成する第１保護部と、
前記第１保護データを生成するたびに前記セッション鍵へ対してのナンス値を更新するナンス更新部と
を有し、
前記画像データは、前記パケットデータ内に格納され、
前記高速データ送信は、前記ナンス値の一部または全部の送信を含み、
前記ナンス値の一部または全部は、前記拡張パケットヘッダ外に格納されて送信される
情報処理装置を備える移動体装置。
（２０）
他の情報処理装置と通信を行って、画像データを含むフレームのデータを高速データ送信する際に、拡張パケットヘッダおよびパケットデータを含む拡張パケットを前記他の情報処理装置に送信する通信部と、
セッション鍵を導出し、前記セッション鍵を用いて前記パケットデータの第１保護データを生成する第１保護部と、
前記第１保護データを生成するたびに前記セッション鍵へ対してのナンス値を更新するナンス更新部と
を有し、
前記画像データは、前記パケットデータ内に格納され、
前記高速データ送信は、前記ナンス値の一部または全部の送信を含み、
前記ナンス値の一部または全部は、前記拡張パケットヘッダ外に格納されて送信される
情報処理装置を備える通信システム。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
１２０１ 通信システム， １２１１ イメージセンサ， １２１２ アプリケーションプロセッサ， １２１３ ディスプレイ， １３０１ 画素， １３０２ 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. 他の情報処理装置と通信を行って、画像データを含むフレームのデータをデータ通信する際に、パケットヘッダおよびパケットデータを含むパケットを前記他の情報処理装置に送信または前記他の情報処理装置から受信する通信部と、
    セッション鍵を用いて前記パケットデータの保護データを生成、検証、または復号する保護部と、
    前記保護データを生成、検証、または復号するたびに前記セッション鍵へ対してのナンス値を更新するナンス更新部と
    を有し、
    前記画像データは、前記パケットデータ内に格納され、
    前記データ通信は、前記ナンス値の一部または全部の送信または受信を含み、
    前記ナンス値の一部または全部は、前記パケットヘッダ外に格納されて送信または受信される
    情報処理装置を備える通信システム。
JP2022546215A 2020-09-01 2021-08-19 情報処理装置、移動体装置、および通信システム Active JP7679388B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2020147113 2020-09-01
JP2020147113 2020-09-01
PCT/JP2021/030286 WO2022050057A1 (ja) 2020-09-01 2021-08-19 情報処理装置、移動体装置、および通信システム

Publications (3)

Publication Number Publication Date
JPWO2022050057A1 JPWO2022050057A1 (ja) 2022-03-10
JPWO2022050057A5 JPWO2022050057A5 (ja) 2023-05-23
JP7679388B2 true JP7679388B2 (ja) 2025-05-19

Family

ID=80490777

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022546215A Active JP7679388B2 (ja) 2020-09-01 2021-08-19 情報処理装置、移動体装置、および通信システム

Country Status (4)

Country Link
US (1) US12375456B2 (ja)
JP (1) JP7679388B2 (ja)
CN (1) CN116076057A (ja)
WO (1) WO2022050057A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3998179A4 (en) * 2019-07-09 2023-04-26 Hosiden Corporation CONTROL DEVICE
WO2023223820A1 (en) * 2022-05-18 2023-11-23 Sony Semiconductor Solutions Corporation Imaging devices, host devices, and method
JPWO2023228439A1 (ja) 2022-05-23 2023-11-30
CN119211708A (zh) * 2024-09-25 2024-12-27 维沃移动通信有限公司 图像处理电路、方法、电子设备及芯片

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014523192A (ja) 2011-07-07 2014-09-08 ベラヨ インク デバイス及びサーバの通信におけるファジーな認証情報を用いた暗号化によるセキュリティ
WO2018225449A1 (ja) 2017-06-09 2018-12-13 ソニーセミコンダクタソリューションズ株式会社 映像送信装置および映像受信装置
WO2020129685A1 (ja) 2018-12-20 2020-06-25 ソニーセミコンダクタソリューションズ株式会社 通信装置および通信方法、並びにプログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2971599B1 (fr) * 2011-02-11 2013-03-15 Jean Luc Leleu Procede de transaction securisee a partir d'un terminal non securise
US20170149748A1 (en) * 2015-11-25 2017-05-25 Ty Lindteigen Secure Group Messaging and Data Steaming
US10291814B2 (en) * 2016-10-14 2019-05-14 Intel Corporation Transmission of encrypted image data
US11039092B2 (en) * 2017-11-15 2021-06-15 Nvidia Corporation Sparse scanout for image sensors
US11064153B2 (en) * 2018-08-21 2021-07-13 Gopro, Inc. Methods and apparatus for encrypting camera media
US11902775B2 (en) * 2021-05-28 2024-02-13 Cisco Technology, Inc. Encrypted nonces as rotated device addresses
US20240305987A1 (en) * 2023-03-08 2024-09-12 Qualcomm Incorporated Wireless packet header protection

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014523192A (ja) 2011-07-07 2014-09-08 ベラヨ インク デバイス及びサーバの通信におけるファジーな認証情報を用いた暗号化によるセキュリティ
WO2018225449A1 (ja) 2017-06-09 2018-12-13 ソニーセミコンダクタソリューションズ株式会社 映像送信装置および映像受信装置
WO2020129685A1 (ja) 2018-12-20 2020-06-25 ソニーセミコンダクタソリューションズ株式会社 通信装置および通信方法、並びにプログラム

Also Published As

Publication number Publication date
CN116076057A (zh) 2023-05-05
US12375456B2 (en) 2025-07-29
WO2022050057A1 (ja) 2022-03-10
JPWO2022050057A1 (ja) 2022-03-10
US20230164123A1 (en) 2023-05-25

Similar Documents

Publication Publication Date Title
JP7721553B2 (ja) 情報処理装置、移動体装置、および通信システム
JP7679388B2 (ja) 情報処理装置、移動体装置、および通信システム
JP7785688B2 (ja) 情報処理装置、移動体装置、および通信システム
JP7793558B2 (ja) 情報処理装置、移動体装置、および通信システム
US10755156B2 (en) Configurable integrity protected link for secure accelerator communication
US9596075B2 (en) Transparent serial encryption
EP3751781B1 (en) Overhead reduction for link protection
JP6126980B2 (ja) ネットワーク装置およびネットワークシステム
US11156987B2 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
JP7721527B2 (ja) 通信装置および通信方法、並びにプログラム
US20240281258A1 (en) Automotive image sensor, image processing system including the same and operating method thereof
US12052231B2 (en) Method and apparatus for managing reception of secure data packets
US11294846B2 (en) System, apparatus and method for secure communication on a bus
US20220011749A1 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
JP2017121091A (ja) Ｅｃｕ、及び車用ネットワーク装置
US11599649B2 (en) Method and apparatus for managing transmission of secure data packets
JP2018182767A (ja) Ｅｃｕ、ネットワーク装置、及び車用ネットワーク装置
CN116803050A (zh) 信息处理设备、移动设备及通信系统
WO2021222641A1 (en) Intelligent controller and sensor network bus, system and method including a message retransmission mechanism
US20250350447A1 (en) Asymmetrical multi-channel communication security
US20250192986A1 (en) Information processor, mobile body apparatus, and communication system
CN118435179A (zh) 数据处理装置
JP7289709B2 (ja) 情報処理装置、情報処理方法及びプログラム
WO2023223821A1 (ja) 送信装置、受信装置、情報処理方法、プログラム、および通信システム
KR20250131050A (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: 20230118

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240704

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: 20250408

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20250507

R150 Certificate of patent or registration of utility model

Ref document number: 7679388

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150