インパルス入力は時間幅が無限小で、振幅は無限大、かつ積分すると1であるものです。実現はできませんが、数式の上でシステム特性を調べるのに有用です。

システムに対して瞬時に衝撃的なインパルス入力を与えるとその応答として安定して収束するのか、不安定になり発散するのか、いわゆるシステムそのものの特性が現れます。これがインパルス応答です。

理想のインパルス信号は現実には生成できませんので試験等で使用するには近似したものを使用します。

インパルス信号はラプラス変換すると1となるのも特徴です。つまり、システム伝達関数のインパルス応答特性を時間領域に逆ラプラス変換する場合、s領域での入力は1なので伝達関数そのものの特性を調べることになります。これがインパルス応答の重要な部分です。

さて、インパルス入力というものがわかったところで、システムにステップ入力を与えた場合と比較していきます。

下の表に、システム伝達関数G(s)が、定数K、積分1/sおよび1次遅れ1/(1+Ts)の場合に、それぞれインパルス入力、ステップ入力を与えた場合の時間関数g(t)を記載しています。

以下にシステムが定数、積分、一次遅れの場合に入力に対してどのような出力となるかを図解で解釈していきます。

s領域の伝達関数が定数の場合①②は時間領域のシステムも感覚通りに理解できます。例えば、伝達関数が定数Kの場合には入力が1の場合は出力はK倍のKになります。時間領域でも入力1に対して出力はKになります。どの条件でも出力は入力のK倍となります。

次は伝達関数が積分の場合③④です。数学的な解釈ではインパルス信号の定義や積分の意味からインパルス入力に対する応答は1の固定値で、ステップ入力に対する積分応答は出力が線形に増加することがわかります。s領域の伝達関数から解釈するとこのように理解するのに迷いはないとおもいます。

今度は逆に時間領域のシステムが1または定数の場合②③から考えてみます。つまり、g(t)=1(定数)の場合です。これは物理的にはどのような状態を意味するのでしょうか。ちょっと解釈に迷うところですが、入力に対して出力の変化がないこと、つまり、システムの時間経過において状態の変化がないことを意味しています。

ちょっと抽象的な表現のため、具体的な例を次節「運動方程式での解釈」で運動方程式を使って説明します。

最後に、システムが一次遅れ特性をもつ場合⑤⑥です。積分特性に比べて直感的に動作を解釈しやすいと思います。

積分特性を物理的に解釈するために、摩擦を無視した質量Mの物体に外力f(t)を与えたときの速度v(t)について考えます。

時間領域の運動方程式において、外力f(t)により生じる加速度a(t)は質量Mが一定であれば外力f(t)に比例します。つまり、入力を外力f(t)、出力を加速度a(t)とすると、入出力間の伝達関数は①②の定数に相当します。

物体の速度v(t)は加速度a(t)の時間積分ですので、外力f(t)からみるとv(t)は積分器を通したものになります。

ここから本題に入ります。静止している物体に外力としてインパルス入力を与えると物体は初速度V₀で運動を始め、摩擦がない空間では質量Mによる慣性によりV₀の等速運動を続けます③。つまり、入力に対して時間経過において速度v(t)の状態変化はありません。

これが、時間関数g(t)が一定であるシステムにインパルス入力を与えた積分動作の物理的解釈です。

外力f(t)をステップ入力にした場合は、物体は一定の加速度a(t)で等加速度運動し、速度v(t)は線形に増加する積分動作④をします。

ステップ入力自体のラプラス変換は積分と同じ1/sになるため、積分システムにステップ入力を与えると1/s²の特性で出力はランプ関数になります。

現実には摩擦が存在するので、外力f(t)をステップ入力で与えると、摩擦力と釣り合い、速度v(t)は1次遅れになります。

WebSocketを一言で表すと、小さなサイズのデータフレームでリアルタイムに双方向通信ができるHTTPの欠点を補ったプロトコルです。

WebSocketはそう新しいプロトコルでもないのですが、使用するにはブラウザが対応していることが前提です。現在では身近なブラウザではほぼ大部分が対応しているために問題はありません。

WebSocketの汎用的な解説詳細は専門のWEBエンジニアが得意とするところで、ここではどちらかといえば番外で応用する側ですので組み込みマイコンシステムで実現するにあたり特有な部分に限定して解説します。

WebSocketを実装するにあたっては組み込み系のエンジニアにとってはHTMLとJavaScriptの使い勝手が組み込みプログラミングとは少し違うため慣れていない場合は苦労するのではないでしょうか。

WebSocketを開始するきっかけはクライアント側のブラウザからHTMLの中に埋め込んだJabaScriptで記述したWebSocketリクエストを送ることです。これはHTMLページを起動するときにリクエストを発行してもよいし、ページ内に作成した接続開始ボタンを押したときにリクエストを発行する仕様にしてもよいです。

WebSocket通信はしくみを理解するのはそう難しくはないですが、初めての実装は結構大変です。実装での最大のヤマはブラウザで発行されたWebSocketキーからブラウザへ返すアクセスキーを生成するところです。

アクセスキーさえ生成できれば、あとはHTMLとJavaScriptを駆使するだけですので組み込み系の人にとってはちょっとなじみは薄いかもしれませんがWEBプログラミングに精通している人ならばなんのことはないと思われます。

それではWebSocket通信のコネクション確立までの手順を確認していきます。

以下の図がブラウザからサーバーにアクセスするところから始まるWebSocketのコネクション確立までの流れです。

① まず通常のようにサーバーにアクセスするためにブラウザにIPアドレス/ポートを指定するとブラウザからサーバーへHTTPリクエストが送られます。

② サーバーはブラウザからGETメソッドを受けて、レスポンスを返すのですが、その中にJavaScriptで記述したWebSocketを起動するためのリクエストを埋め込んでおきます。大事なポイントはここで一旦通信を切断しておくことです。

③ 数秒おいてからブラウザはサーバーから送られたレスポンス内のJavaScriptを実行してWebSocketキーを含んだHTTPアップグレードリクエストをサーバーに送ります。

WebSocketを開始する場合はブラウザからHTTPリクエストを受け取った後にレスポンスのメッセージボディにJavaScriptでWebSocketリクエストを埋め込むところが通常の場合と異なります。

WebSocketを開始するためのコードは大体フォーマットは決まっていて、WebSocketオブジェクトを生成することから始めます。オブジェクト名は任意に指定できます。下記のサンプル例ではwsocketとしています。

下記のJavaScript記述したWebSocketリクエストのコードをリクエストのヘッダー部に埋め込んでおきます。

WebSocketイベントとメソッドはJavaScriptのコードで記述し、アプリケーションに応じた処理内容にします。

ブラウザ側でWebSocketリクエストコードを実行するとサーバー側へWebSocketキーを含んだHTTPアップグレードリクエストを送信します。

WebSocketコネクション確立のための最大のポイントがブラウザから渡されたWebSocketキーからアクセスキーを生成するところです。

囲んだ24文字のコードがWebSocketコネクションのためにブラウザが発行したキーです。 一例としてサーバーは受信したGETリクエストの空白前のヘッド部に”Sec-WebSocket-Key”があればWebSocketリクエストと認識し、その後に続く24文字分のキー(xxx...xxx==)を抽出します。

この次が最大のヤマ場であるリクエストのWebSocketキーに対するアクセスキーを生成する部分です。

アクセスキーを言葉で表現すると「リクエストで与えられたブラウザが生成したキーに固定値の"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"を連結して、SHA-1ハッシュと呼ばれる暗号化を行い、Base64エンコードを行った値」となっています。

アクセスキーを生成する手順は上記の流れですが、SHA1ハッシュ値を生成するアルゴリズムは難解のため、これすべてを自力でするのではなくどこかの汎用的なライブラリを利用すべきです。

BASE64エンコードに関しては内容はそう難解ではありませんが、これもライブラリ情報は多いため、利用するほうが得策かもしれません。

アクセスキーが生成できたら、WebSocketコネクション確立のためのHTTPアップグレードレスポンスをブラウザへ返します。

レスポンスのフォーマットは下例のとおりでよいと思います。レスポンス一行目のステータスラインは"HTTP/1.1 101 Switching Protocols"と"HTTP/1.1 101 OK"のどちらでも機能するようです。

生成したアクセスキーが有効であることがブラウザで認識されるとWebSocketコネクションが確立し、WebSocketプロトコルによる双方向通信が始まります。いわゆるサーバーとクライアント(ブラウザ)間でハンドシェイクのやり取りが成立したということになります。

確立するとopenイベントが発火し、定義したイベント内容が実行されます。例えばonopenイベントで”Websocket Connect!!"のメッセージを表示させる処理など記述しておけばよいでしょう。

WebSocketコネクションが確立すると任意のタイミングでブラウザ、サーバー間で双方向通信ができるようになります。WebSocket通信では送受信データにはテキストのみならずバイナリも扱うことができます。

データはWebSocketデータフレームとよばれるフォーマットに従ったものを送受信時に扱います。

データフレームの詳細は下記リンクのサイトで確認してみてください。

一度に送るデータが127文字以下でテキストかバイナリに限定する場合は比較的単純です。

データフレームのフォーマットは1バイト単位のブロックで構成されています。１番目のバイトブロックは通信データが最後のパケットであるかの指定およびデータの種類を指定します。２番目のバイトブロックではデータのマスク有無およびデータ長を指定します。

データのマスク有無ですが、これは決まり事でブラウザからのデータはマスクを付加し、ブラウザへのデータはマスクを付けないことになっています。

言葉での説明はわかりにくいのですが、送受信するデータの具体的な適用例で確認すれば理解しやすいと思いますので、送信、受信の場合で解説していきます。

具体的な例としてブラウザがテキスト文字列"test"を送信する場合で確認します。送受信はTCPソケット通信で行われます。

ブラウザからの送信ではsendメソッドを使用します。

4文字テキストの場合、ブラウザは10バイト分のWebSocketデータフレームを送信します。サーバー側で受信するTCPデータバッファをdata_buffer[]とすると実際にこの受信バッファに読み込まれるデータの例は以下のようになります。

4文字テキストデータは単独パケットなので1番目バイトブロックdata_buffer[0]は先頭ビットFINは1、テキストデータのためopcodeは1となるので16進数表記で0x81となります。

2番目バイトブロックdata_buffer[1]はブラウザからのデータでマスク付きなので先頭ビットMASKは1、データのpayload長は4なので16進数表記で0x84となります。

3-6番目バイトブロックdata_buffer[2]-[5] はブラウザから付加されたマスクキーです。これらは同じデータを再度送っても都度変わります。

7番目以降のバイトブロックdata_buffer[6]-[9] の文字数分がブラウザから送信するテキストデータにマスクでコード化されたものです。コード化したデータはマスクキーを使用して復号することで抽出データunmasked_str[i]を取得します。

抽出データunmasked_str[i]はMask_Key[i]とmasked_data[i]のXOR(論理演算)によりUnMask(復号)して取得します。

ブラウザは任意のテキストデータやバイナリデータ以外にも送信するコードがあります。その一例としてcloseメソッドでwsocket.close()を実行した場合のやり取りされるデータを確認してみます。

この場合のブラウザから送信されるデータ列は実データを含まない6バイト分のデータフレームです。最初のバイトブロックのopcodeがcloseメソッドを実行したときは0x8となっています。マスクキーも送信されてきますがここでは意味はありません。

サーバー側で受信した先頭のバイトブロックdata_buffer[0]が0x88であればブラウザでcloseメソッドを実行したことがわかります。

WebSocketのopcodeには、他に0x9(Ping), 0xA(Pong)がよく使用されます。切断したときの処理などに利用できます。

実際にやり取りされる具体的なデータで確認していくとすぐに理解できたのではないでしょうか。次はサーバーからの送信を確認していきます。

今度はサーバー内のテキスト文字列"test"をブラウザに送信する場合で動作を確認します。サーバーからの場合はマスクを必要としないのできわめてシンプルです。

サーバー内のテキストデータ*str_send="test"をブラウザに送信して表示させる場合で確認していきます。

4文字テキストを送信する場合はマスクは使用せず、WebSocketデータフレームの1番目と2番目バイトブロックに送信するデータのフォーマットを指定して、つづいてテキストデータを送信するだけです。

HTTPプロトコルに比べて送信時は特にヘッダが小さいため送信する情報量が小さくてすむのが特徴です。送信データが小さいものほど差は顕著です。

ブラウザへはTCPのsend関数(TCP処理系により異なる)で送信します。

ブラウザではデータを受信したときにonmessageイベントが発火しますので、テキストを表示させるなど実施したい処理を設定しておいてください。

これらの送信ブロックを任意のタイミングで送信してブラウザに反映させることができるのがWebSoketの特徴です。

これまでの内容を実機で確認する場合の配線はこれまでと同じです。

ブラウザからサーバーのIPアドレス/ポートを指定するとボディメッセージに記述したHTMLページが開きます。

WebSocketコネクションを確立するために"Connect"ボタンを押します。このサンプルでは”Connect"ボタンを押してからWebSocketリクエストを送っています。

WebSocketコネクションが確立すると発火するopenイベント内に"Websocket Connectioned!!"を表示するようにしています。

HTMLのスライダーを操作するとJavaSriptで設定したデータ範囲の数値が"Slider output"に表示されます。これはブラウザ側で生成した値で送信するデータですのでWebSocketコネクション確立にかかわらず表示されます。

WebSocketコネクションが確立した状態でスライダーを操作すると同時に"NUCLEO Loopback"に数値が表示されます。これはサーバーが受信したデータをそのままブラウザに送り返しているデータですので双方のデータはほぼリアルタイムに連動しているところがWebSocketによる双方向通信の特徴です。

"Close"ボタンを押すとcloseメソッドを実行してコネクションを切断するようになっています。Closeイベントが発火すると"Websocket DisConnected.."を表示するようにしています。

ひとたびWebSocketコネクションが確立するとWebsocketプロトコルによる双方向通信は比較的シンプルに実現できます。ただ、実際の運転においてはTCPソケット通信に比べて通信が不安定になりがちですので安定した通信を実現するにはあと一工夫必要です。

次のデモ動画はサーバー内の変数をブラウザに送って表示させるものです。送信のサンプリングレートは100msです。

これくらいの表示速度であれば動作を伴うセンサー値などのリアルタイムモニターに応用できるのではないでしょうか。

送信周期を100ms以下にすると不安定で、組み込み機器のリアルタイム通信としてはこの速度では少し物足りずWebSocketの利点が活かされていないようですが、現状ではこんなものかもしれません。フリーズや切断する原因を特定して可能であればより安定して高速な通信の実現を今後の課題としておきます。