障害発生の種類とその発生位置を含む警報情報を転送する光ネットワークにおける光ネットワーク装置であって、受信した信号から警報情報を検出し、該警報情報から警報の内容を記述した警報コード情報を生成し、出力する受信側処理部と、該受信側処理部からの信号を切り替えて、転送する転送部と、該転送部から受信した信号に対し、前記警報コード情報と自処理部の設定情報と該受信側処理部の設定情報に基づいて、警報情報について信号の置き換え処理をして、該受信した信号を出力する送信側処理部と、を備えることを特徴とする光ネットワーク装置。前記光ネットワークは、OpticalTransportNetworkであることを特徴とする請求項1に記載の光ネットワーク装置。前記警報情報は、FaultTypeandFaultLocationreportingchannelの情報を含むことを特徴とする請求項2に記載の光ネットワーク装置。前記転送部は、クロスコネクト処理部であることを特徴とする請求項1に記載の光ネットワーク装置。前記警報コード情報は、受信した信号のオーバヘッドの未使用領域を使って転送されることを特徴とする請求項1に記載の光ネットワーク装置。前記警報コード情報は、受信した信号に特別に設けられたヘッダを使って転送されることを特徴とする請求項1に記載の光ネットワーク装置。前記警報コード情報は、受信した信号とは別経路を使って転送されることを特徴とする請求項1に記載の光ネットワーク装置。クロスコネクト装置に適用されることを特徴とする請求項1に記載の光ネットワーク装置。Muxponder装置に適用されることを特徴とする請求項1に記載の光ネットワーク装置。Repeater装置に適用されることを特徴とする請求項1に記載の光ネットワーク装置。光モジュールの光出力の停止制御を行なう処理装置に適用されることを特徴とする請求項1に記載の光ネットワーク装置。前記受信側処理部と、前記送信側処理部とは、それぞれ別個のシェルフに搭載される装置であることを特徴とする請求項1に記載の光ネットワーク装置。前記受信側処理部と、前記送信側処理部とは、それぞれ別個の半導体チップに搭載される装置であることを特徴とする請求項1に記載の光ネットワーク装置。前記受信側処理部と、前記送信側処理部とは、それぞれ別個の半導体チップに搭載され、それらの機能はプロセッサによって実行されるファームウェアで実現されることを特徴とする請求項1に記載の光ネットワーク装置。以下の実施形態においては、規格に従って高速通信を実現する場合に必要となる機能ブロックの数を削減し、コストを低減することのできる光ネットワーク装置を提供する。以下の実施形態の一側面における光ネットワーク装置は、障害発生の種類とその発生位置を含む警報情報を転送する光ネットワークにおける光ネットワーク装置であって、受信した信号から警報情報を検出し、該警報情報から警報の内容を記述した警報コード情報を生成し、出力する受信側処理部と、該受信側処理部からの信号を切り替えて、転送する転送部と、該転送部から受信した信号に対し、前記警報コード情報と自処理部の設定情報と該受信側処理部の設定情報に基づいて、警報情報について信号の置き換え処理をして、該受信した信号を出力する送信側処理部とを備える。以下の実施形態によれば、規格に従って高速通信を実現する場合に必要となる機能ブロックの数を削減し、コストを低減することのできる光ネットワーク装置を提供することができる。本実施形態では、OTNMuxponder及びOTNのCrossconnectSwitching機能を有する装置において、ITUTG709G798にて標準化されているODUOverheadOHに関するSignalReplacement機能を実装する際の、新しい機能Block構成を示す。すなわち、本実施形態では、重複している機能Blockを取り除くことを考える。図9は、本実施形態におけるXC装置の機能Blockに着目した図である。図9に示すように、XC装置は、入出力側にLOODUkBlock40を備え、このBlockを通過した信号は、XC処理部XCONBlockX41によって切り替え処理される。この際、各LOODUkBlock内部の各機能ブロックのうち、LOODUkBlock40-1では、SyncRx42、ODUIGOHODUTIGOHRX43、ODUEGOHODUTEGOHTX44、MSINS45以外のブロックを削除する。また、LOODUkBlock40-2では、ODUIGOHODUTIGOHTX46、SyncRX42、ODUEGOHODUTEGOHRX47、MSINS45以外のブロックを削除する。そして、後述するように、削除したブロックの機能を補償するブロック、ODUIGOHODUTIGOHTXをEgress側のみとすることにより、Ingress側のTXBlockとEgress側のRXBlockを取り除く。Ingress側のTXBlockを取り除くとIngress側にて検出した警報をトリガとして、Ingress側に対して送信される警報情報に基づいて、Ingress側の制御状態に従ったSignalReplacementが出来なくなる。また、Egress側のRXBlockを取り除くことにより、Egress側にて警報を検出できなくなる。これらの問題を解決するため、図10に示すように、下記3つの処理部を搭載する。1XC接続先のEgress側への転送情報としてAlarmCodeInformationを定義し、AlarmCodeInformationの処理、転送処理を行うALMCODE転送部50を搭載する。ここで、AlarmCodeInformationを図11に示す。AlarmCodeInformationは以下の情報で構成される。1AlarmLevelMax値Alarmに対し、検出したAlarmlevelの最大値をAlarmLevelとして転送する。ここでは、2ビットの情報としている。2FWFTFLENDISIngress側で本来挿入するForwardFTFLの情報をXC接続先のEgress側に転送するか否かを示す情報。3TCM1ENDISIngress側に設定されたTandemConnectionMonitoring値をXC接続先のEgress側に転送するか否かを示す情報。4TCM2ENDISIngress側に設定されたTandemConnectionMonitoring値をXC接続先のEgress側に転送するか否かを示す情報。5TCM3ENDISIngress側に設定されたTandemConnectionMonitoring値をXC接続先のEgress側に転送するか否かを示す情報。6TCM4ENDISIngress側に設定されたTandemConnectionMonitoring値をXC接続先のEgress側に転送するか否かを示す情報。7TCM5ENDISIngress側に設定されたTandemConnectionMonitoring値をXC接続先のEgress側に転送するか否かを示す情報。8TCM6ENDISIngress側に設定されたTandemConnectionMonitoring値をXC接続先のEgress側に転送するか否かを示す情報。9LCKFlagIngress側でODUkLCKを本来挿入する情報をXC接続先のEgress側に転送するか否かを示す情報。なお、TCM16ENDISは、それぞれITUTの上記規格に従った意味を持ち、それぞれ独立してENDIS値を保持する。また、3-9の情報は、制御情報処理Block52から、Egress側に送信して設定してもよい。この場合は、AlarmCodeInformationに3~9の情報を含める必要は無い。2Ingress側に対する制御処理情報及びクロスコネクト情報をまとめてEgress側の制御を行なう制御情報処理Block52を搭載する。31のAlarmCodeInformationと2の制御処理情報及びEgress側に対する制御処理情報によるSignalReplacement、及び、OH動作決定を行なうALMCODE受信部51を搭載する。なお、図10において、XC処理部XCONBlockX41は、双方向に信号を通すので、図10のように、便宜上、XC処理部41の片側をA側、他方をB側と定義する。ProvAは、A側のBlockにおいて使用される設定情報であり、ProvBは、B側のBlockにおいて使用される設定情報である。以下に上記1のALMCODE転送部の具体的な処理を説明する。図12及び図13は、ALMCODE転送部を説明する図である。Ingress側にて検出する各Alarmに対して、それぞれAlarmLevelを定義する。図12にAlarmLevel及び、FTFLTriggerを示す。図12にあるように、Ingress側で検出するAlarmには、HOBlockで検出する3つのAlarmSyncBlockで検出する3つのAlarmOTUEGOHRXで検出する3つのAlarmODUEGOHRXで検出する6つのAlarmODUTEGOHRXで検出する7つのAlarmがある。それぞれのAlarmについて、AlarmLevelとFTFLTriggerの設定例を示したのが、図12である。AlarmCode転送部50において、Ingress側のRXBlockにて検出したAlarmのAlarmLevelを比較し、発生しているAlarmの中での一番高いAlarmLevelをAlarmCodeInformationにセットして、XC処理部41の接続先のEgress側へ転送する。また、FTFLTrigger設定が成されているAlarmの検出に対し、AlarmCodeInformationのFWFTFLENDISに、イネーブルをセットする。SignalReplacementを実施しない場合には、Egress側の閾値より小さい値を設定する。例えば、SignalReplacementを行なう判定用の閾値が2で、2以上の場合にSignalReplacementを行なう場合、AlarmLevel0or1とする。Ingress側のオーバヘッド処理の有無により、AlarmLevel0とする。FWFTFLを挿入しない場合には、FTFLTrigger0とする。図13にあるように、A側においては、ProvAは、TCM123456を、EnableあるいはDisableに設定するものである。B側においては、ProvAはFTFLを設定するもので、ProvBは、TCM123456をEnableあるいはDisableに設定するもので、これと共に、FTFLを設定するものである。図14~図16は、AlarmCodeInformationの転送方法を説明する図である。AlarmCodeInformationは、以下のいずれかで、Egress側へ転送してよい。1つ目は、図14の斜線で示されるように、クロスコネクトされるODUFrameのOHの未使用領域RESを用いてAlarmCodeInformationをMappingする。2つ目は、図15のように、ODUFrameに独自のOverheadHeaderを付加し、そのOverheadHeaderにAlarmCodeInformationをMappingする。3つ目は、図16のように、制御情報処理Block52を経由し、クロスコネクト接続先のEgress側BlockにAlarmCodeInformationを転送する。以上により、AlarmCodeInformationを使って、Ingress側にて検出したAlarmをEgress側へ伝達することが可能となる。以下に上記2の制御情報処理Blockの具体的処理を説明する。制御情報処理Blockの機能は、Ingress側に対する制御情報とクロスコネクト情報クロスコネクトの存否をまとめてIngress側の状態としてEgress側へ送信することである。制御情報は、FTFLOperatorID及び、FTFLOperatorSpecific情報クロスコネクト接続情報どのフレームがどのBlockに出力されるかという情報TCMxのEnableDisable情報ここで、以降において、TCMxは、TCM16の全てを一括して示すものである。但し、AlarmCodeInformationに含まない場合LCKINS但し、AlarmCodeInformationに含まない場合これらの情報をEgress側へ転送して制御に用いることにより、Egress側にてIngress側の制御状態を把握するこが可能となる。以下に上記3のALMCODE受信部を説明する。ALMCODE受信部において、ALMCODE転送部により伝達されたAlarmCodeInformationと、制御情報処理Blockにより転送されたIngress側とXC処理部の情報、すなわち、FTFLOperatorID及び、FTFLOperatorSpecific情報クロスコネクト接続情報TCMxのEnableDisable情報但し、AlarmCodeInformationに含まない場合LCKINS但し、AlarmCodeInformationに含まない場合及び、Egress側に対する制御情報TCMxのEnableDisable情報FTFLOperatorID及び、FTFLOperatorSpecific情報を用いて、Egress側から出力するODUkOHを決定し出力する。以下の図においてそれぞれのSignalReplacementにおいて各処理部がどのように判断し、どのようなOHを出力制御するかについて具体的に示す。図17及び図18は、ODUkAISにSignalReplacementするときのTCMOH値の制御情報処理Blockにおける判断及び処理を説明する図である。図17は、どのような処理を行うかの判断を行なうためのテーブルである。図17のテーブルにおいて、TCMは、6個の設定値があるが、TCMxのENイネーブル/DISとディスエーブルDISと、TCMxのB側のProvBのイネーブルENとディスエーブルDISとの組み合わせで、4通りの場合がある。これらの場合について、AlarmCodeInformationのAlarmLevelが0又は1の場合と、2の場合と、3の場合とで処理が分かれる。AlarmLevelが0又は1の場合には、ODUkAISのSignalReplacementを行なわない。AlarmLevelが2又は3のとき、ODUk-AISのSignalReplacementを行なう。ProvAがENで、ProvBがENである場合は、AlarmLevelが何であっても、ODUkAISには、ProvBB側の設定値を挿入する。ProvAがDISで、ProvBがENである場合にも、AlarmLevelが何であっても、ODUkAISにProvBを挿入する。ProvAがENで、ProvBがDISの場合には、AlarmLevelが0、1、2の場合には、ODUkAISを全て0とする挿入を行い、AlarmLevelが3の場合に、全てFとするReplacementを行なう。ProvAがDISで、ProvBもDISの場合には、AlarmLevelが0又は1のときは、ODUkAISはそのまま透過PassThruし、その他の場合には、ODUkAISを全てFとするReplacementを行う。ここで、ProvAProvBは、A側の設定、B側の設定という意味である。図18にあるように、A側のALMCODE転送部から、上記の情報が、目的のLOODUkBlockのALMCODE受信部に送られる。制御情報処理Blockの転送する情報にはクロスコネクト接続情報が含まれ、A側のあるLOODUkBlockから送信された信号が、XC処理部XCONBLOCKによって切り替え処理された後の出力先のB側LOODUkBlockを特定することができる。制御情報処理Blockは、A側から通知されたAlarmCodeInformationやその他の情報より、図17のテーブルに従った判断を行い、B側のLOODUkBlockのODUEGOHODUTEGOHTXにおいて、ODUkAISの生成を行ない、信号を出力する。図19及び図20は、FTFLOHの挿入値の制御情報処理Blockにおける判断及び処理を説明する図である。図19は、どのような処理を行うかの判断テーブルである。図19のテーブルにおいて、TCMは、6個の設定値があるが、TCMxは、これら6個のTCMの設定値の論理和をとった結果を用いる。したがって、6個のTCMのうち、1つでもENがあれば、TCMxは、ENであると判断される。FWFTFLのEN、DISについても、全てのビットの論理和をとった結果を用いる。TCMxのA側のProvAのイネーブルENとディスエーブルDISと、TCMxのB側のProvBのイネーブルENとディスエーブルDISとの組み合わせで、4通りの場合がある。それぞれの場合について、AlarmCodeInformationとして送られてくるFWFTFLが0DISの場合と、1ENの場合とがあり、ENの場合には、FTFLの0127ビットFWFTFLと128255ビットBWFTFLで処理が分かれる。FWFTFLが0の場合には、TCMxのProvAProvBがどのような組み合わせでも全てFTFLOHをそのまま透過PassThruさせる。また、FWFTFLが1の場合でも、FTFLの128255ビットBWFTFLはそのまま透過させる。FWFTFLが1の場合、FTFLの0127ビットFWFTFLについては、TCMxのProvAがENの場合に、FWFTFLに、ProvAを挿入し、その他の場合には、FWFTFLをそのまま透過PassThruさせる。ここで、ProvAProvBは、A側の設定、B側の設定という意味である。図20にあるように、A側のALMCODE転送部からAlarmCodeInformation等がB側のALMCODE受信部に送信され、これらの情報がODUEGOHODUTEGOHTXにおいて、FTFLEGOHの生成に使用される。図21及び図22は、ODUkOCIにSignalReplacementするときの制御情報処理Blockにおける判断及び処理を説明する図である。ODUkOCIは、光ネットワーク装置でXC処理部による切り替え処理がなされているか否かを示す情報である。クロスコネクト処理が行なわれていない場合についてのみ、SignalReplacementを行なう。図211のテーブルにおいて、TCMは、6個の設定値があるが、TCMxは、これら6個のTCMの設定値の論理和をとった結果を用いる。したがって、6個のTCMのうち、1つでもENがあれば、TCMxは、ENであると判断される。図211にあるように、例えば、TCMxのProvAが何であっても、ProvBがENの場合には、ODUkOCIにProv-Bを挿入し、TCMxのProvBがDISの場合には、ODUkOCIを全て66で埋め尽くす処理を行う。ODUkOCIを全て66で埋め尽くした時のデータの様子を図212に示す。データのペイロードを埋め尽くしている01100110は、66の2進数表示である。図22にあるように、A側のALMCODE転送部からクロスコネクトの存否情報ここでは、否がB側のALMCODE受信部に送信され、これらの情報がODUEGOHODUTEGOHTXにおいて、ODUkOCIの生成に使用される。図23及び図24は、ODUkLCKにSignalReplacementするときの制御情報処理Blockにおける判断及び処理を説明する図である。図231において、A側から送られてくるLCKINS側に入力された信号は、AB側LOODUkBlockにおいてループバックされる。このようなとき、AB側のALMCODE転送部からLCKINSがB側のALMCODE受信部に送信され、この情報がODUEGOHODUTEGOHTXにおいて、ODUkLCKの生成に使用される。上記説明のとおり、1~3により、Ingress側のTXBlockを取り除くことにより、Ingress側にて検出した警報をトリガとして、Ingress側に対して送信され、制御された制御状態に従ったSignalReplacementが出来なくなる問題及び、Egress側のRXBlockを取り除くことにより、Egress側にて警報を検出できなくなる問題を解決することが可能となる。前述のとおり、1主信号FrameのOHに関し、AlarmCodeInformationを定義しAlarmCodeInformationの処理、転送処理を行う。2Ingress側に対する制御処理情報及びクロスコネクト接続情報をまとめてEgress側の制御のために転送する制御情報処理Blockを搭載する。31のAlarmCodeInformationと2の制御処理情報及びEgress側に対する制御情報によるOH動作決定を行なう。これにより、Egress側にてIngress側のAlarm状態設定状態、制御状態を把握すること、及びクロスコネクト機能を搭載する装置においては、クロスコネクトの接続状態を把握することが可能となる。つまり、OTNMXPや、OTNSW装置において、SignalReplacement機能をG709G798規格どおり提供しつつ、Ingress側とEgress側で重複する機能Blockを取り除くことが可能となり、回路規模の増加による、部品の大容量化、部品点数の増加、消費電力の増大、価格の増加といった問題を解決することが可能となる。特に40G、100GといったOTNMXPやOTNSW装置開発において、回路規模を大幅に削減することが可能となる。本実施形態はOTNNetworkに配置されるODUXC機能の実装有無に依らず、また、LOODUFrameをHOODUFrameにMultiplexDemultiplexする機能の有無に依らず、OTNFrameを処理する装置に適用可能である。図25は、本実施形態が適用されることが想定されるOTNネットワークのイメージ図である。図25の構成では、OTNネットワーク60-1はリング状に構成され、各ノード63が接続されている。各ノード63は、ODUCrossconnect装置や、ODUMultiplexer装置や、ODURepeater装置などである。各ノード63には、他のOTNネットワーク60-2~60-5が接続されたり、Clientネットワーク62-1、62-2が接続される。本実施形態の光ネットワーク装置は、ここで示す、ノード63に対応し、ODUCrossconnect装置、ODUMultiplexer装置、ODURepeater装置などである。図26は、ODUCrossconnect装置の構成を示す図である。図26に示されるように、XCONBlockX、ODUEGOHODUTEGOHRXOTUEGOHRX、ODUIGOHODUTIGOHTXSyncRX及び、3つのMSINSのBlockが削除できている。また、LOODUBlock71は、従来技術の図4と比較すると、ALMCODE転送部及びALMCODE受信部が新たに設けられている代わりに、ODUIGOHODUTIGOHTXODUEGOHODUTEGOHRXSyncRX及び、3つのMSINSのBlockが削除できている。さらに、ClientSignalBlock74は、従来技術の図5と比較すると、ALMCODE受信部が新たに設けられている代わりに、SyncRXODUEGOHODUTEGOHRXODUEGOHODUTEGOHTXODUIGOHODUTIGOHRX及び、2つのMSINSのBlockが削除できている。なお、ClientSignalBlock74では、クライアントネットワーク等からSONETやイーサネット登録商標の信号を受信し、XC処理部75に入力する。この場合、OTNには、SONETやイーサネット登録商標の警報信号は送られないので、ALMCODE転送部は設けられていない。また、HOOTUODUBlock73では、従来技術の図2と比較すると、ALMCODE転送部が設けられている代わりに、OUTIGOHTX、ODUIGOHODUTIGOHTX、ODUEGOHODUTEGOHRXOTUEGOHRX及び、3つのMSINSのBlockが削除できている。なお、HOOTUODUBlock73では、HigherOrderの信号の警報情報は、LowerOrderの信号に含まれて転送されるので、ALMCODE転送部が設けられているが、LowerOrderの信号の警報情報は、HigherOrderの信号に含まれて転送されないので、ALMCODE受信部は設けられていない。なお、制御情報処理Blockは、複数持ってもよい。図28は、図27の構成において、各Blockを別装置として組み立てた場合の構成図である。図28において、図27と同じ構成要素には同じ参照符号を付して、それらの説明を省略する。図28においては、各Blockが四角の線で囲まれている。これは、各Blockがそれぞれ、異なる半導体チップ上、あるいは、異なるシェルフ上に搭載されていることを示している。図28においては、それぞれ異なる半導体チップ上、あるいは、異なるシェルフ上に搭載された各Blockを配線で接続して、全体の光ネットワーク装置を構成している。各半導体チップあるいは異なるシェルフに搭載されるBlockの機能は、ハードウェアで実現されてもよいし、プロセッサが実行するファームウェア等で実現されても良い。図27あるいは図28に示されるBlockを組み合わせることで、ODURepeater装置を構成することも可能である。図29及び図30は、ODURepeater装置のブロック構成図を示す図である。図29は、双方向のRepeater装置であり、図30は、片方向のRepeater装置である。図29において、XC処理部80の両側にLOOTUBlockA81-1、81-2が設けられ、警報情報の転送を制御する制御情報処理Block82が設けられている。LOOTUBlockA81-1、81-2では、従来の構成におけるOTUIGOHTX、ODUEGOHODUTEGOHRXOTUEGOHRX、ODUIGOHODUTIGOHTXSyncRX及び、3つのMSINSのBlockが削除され、代わりに、ALMCODE転送部及びALMCODE受信部が設けられている。図29の構成は、双方向に信号を伝送する構成であるので、A側からB側への警報情報の転送と、B側からA側への警報情報の転送は、対称的である。図30の片方向のRepeater装置では、A側からB側への信号の伝送を記載している。LOOTUBlockA81a-1では、OTUIGOHRXとODUIGOHODUTIGOHTX、2つのMSINSが削除され、ALMCODE転送部が追加されている。一方、LO-OTUBlockB81a-2では、SyncRX、OTUEGOHODUTEGOHRX、OTUEGOHRX及び、1つのMSINSが削除され、代わりに、ALMCODE受信部が追加されている。図27に示されるBlockを組み合わせることで、ODUMuxponder装置を構成することも可能である。図31は、ODUMuxponder装置のブロック構成図を示す図である。図31では、HOOTUODUBlock73をOTU2ODU2処理部として1個設け、LOODUBlock71をODU0処理部として8個設け、ClientSignalBlock74をODU01GbE処理部として8個設けているが、HOOTUODUBlock73は、OTU4ODU4処理部、あるいは、OTU3OODU3処理部、あるいは、OTU1ODU1処理部としてもよい。また、LOODUBlock71は、ODU2処理部、あるいは、ODU1処理部でも構わず、個数も必要な数だけ設けることができる。ClientSignalBlock74も、GbEに限られず、OTNFrameにMapping可能であればどのようなものでも構わず、個数も必要な数だけ設けることができる。ここで、Muxponderは、XC処理部を運用中に設定変更が必ず可能である必要はなく、運用上、切り替え機能が固定である装置、システムも含む。図32は、Egress側のClientSignalBlock処理において、ClientSignalの種類に従ったSignalReplacement処理の説明図である。例えば、MaintenanceSignalである、1GbEにおけるLFSやVcodeの挿入、10GbEにおけるLFの挿入、SONETにおけるAISLの挿入等を、ALMCODE受信部からの情報に従って、ClientSignalMSINSがClientSignalのOHに行い、このようなOHを有するClientSignalをClientSignalOHTXにおいて生成する。例えば、ClientSignalがSONETの場合には、MSINSは、AISの挿入を行なう。図33は、Egress側のClientSignalBlock処理において、ClientSignalの種類に依らずに光モジュールの出力を停止させる処理の説明図である。ClientSignalBlockのALMCODE受信部において受信された警報情報から、制御情報処理Blockが障害の発生を検出した場合には、障害の発生した信号を断にすることが考えられる。この場合、制御情報処理Blockは、光モジュール85の光送信器OSに対し、光出力停止制御を行なって、光信号の発振を停止させる。この機能は、ClientSignalBlockのみではなく、Egress側のLOOTUBlockでも同様の処理を実装してもよい。なお、AlarmCodeInformationに関し、FTFL処理を実施し、TCM処理を実施しない装置においては、AlarmLevel、及び、FWFTFLINSに相当する情報を転送可能であればよく、LCKINSは、制御情報処理Blockが認識可能であれば、Egress側に設定するのみでもよい。また、AlarmCodeInformationに関し、FTFL処理を実施せず、TCM処理を実施する装置においては、AlarmLevelに相当する情報を転送可能であればよく、TCM1ENTCM2ENTCM3ENTCM4ENTCM5ENTCM6ENLCKINSは、制御情報処理Blockが認識可能であれば、Egress側に設定するのみでもよい。AlarmCodeInformationのAlarmLevelに関し、2ビットAlarmLevel0123で表現する記載をしているが、2ビットに限定することなく、3ビット以上でも構わない。また、図12において、MaintenanceSignalを挿入する閾値設定を2以上と記載しているが、AlarmLevelを2ビット以上に拡張した場合、閾値設定は、その拡張に依存して、システムの設計者が決定する。