Reinforce-Lab.'s Blog

わふうの人が書いてます

iPhone7とiOS10のモバイル決済

代わり映えのしないハードウェア

iPhone7とiOS10が発表されました。ハードウェアには、より処理能力の高いプロセッサとメモリの大容量化という定番の進歩と、イヤホン端子の廃止や防塵防滴化など、他社のスマートフォンであれば以前からある付加価値が追加されました。

また、新色 ジェットブラックが追加されました。iPhone3GSのプラスチックの艶やかな黒、そしてiPhone4シリーズのガラスで覆われた艶やかな黒以降、iPhone5およびiPhone6シリーズでは失われていた、艶やかな黒色の再登場です。

ApplePayの日本でのサービス開始

これらのハードウェアの進歩は、もはや毎年繰り返される定番の話題で見るべきところはありません。ですが、ApplePayの日本でのサービス開始がアナウンスされました。このApplePayのサービス開始の一部として、SuicaおよびiDとQUICPayの非接触型決済サービスへの対応がアナウンスされました。

これらの非接触型決済サービスは、非接触型ICカードにFelicaを採用しています。FeliCaは、ソニーが開発した非接触型ICカードの技術方式の名称です。Felicaは日本で広く、しかし日本でのみ広く使われている技術ですが、iPhone7およびApple Watch2のハードウェアがFelicaに対応しました。

これでできることは:

  • ハードウェア: Felicaに対応。
  • サービス: プリペイド方式のSuicaに対応。
    • 国際ブランドの登録クレジットカードからチャージ可能。
  • サービス: ポストペイ方式の非接触決済 iD、QUICPay が利用可能。
    • 国際ブランドの登録クレジットカードと連携させる。

ApplePayを使うと、自分が持っているクレジットカードを登録して、アプリ内およびウェブでの支払いに、その登録情報を使って支払いができます。またハードウェアがFelicaに対応したiPhone7以降であれば、店舗で非接触型決済もできます。

非接触型決済の、日本での現実的な対応

決済には、ブランド会社とカード発行会社そして加盟店管理業者の3つの役割があります。JCBのように、これら3つの役割を兼ね備えた会社もありますが、たいていはそれぞれを担う会社は別です。

ブランド会社はVISAやMasterCardのように決済の仕組みを提供します。カード発行会社はブランドからライセンスを取得してクレジットカードを発行します。加盟店管理業者は、加盟店を開拓して、売上データの受け取り、カード発行会社からの売上代金回収そして加盟店への入金業務を行います。参照: 【第4回】[基礎編] 「イシュアー」と「アクワイアラ」 http://pointi.jp/credit_card/credit_about04.php

日本ではすでに広く非接触型決済のサービスが普及しています。ここでApplePayの加盟店を広げようとしても、時間がかかります。すでにあるSuicaなどが使えるようにしたのは、現実的な対応です。

おサイフケータイとちょっと違うっぽい

AndroidのおサイフケータイやモバイルSuicaのサービスがあるけど、使ったことがないので、同じようなものかなと思ってググッて使い方のページとかを見ていた。結構違うんだなって印象。

iDは、ドコモが運営する決済プラットホームでブランドだから、VISAやMasterCardのような国際ブランドと同じように、そのブランドをクレジットカード発行会社がライセンスして、カードを発行して、iDの加盟店管理業者がカードリーダを店舗に設置する流れのものなんだろう。

そのiDの非接触型決済だと、クレジットカード発行会社にiDの利用を申し込んで、そのカードをAndroidに登録するみたい。だからおサイフケータイは、iDカードというハードウェアの機能をAndroidのハードウェアに転写するイメージ。iDって、あとから追加サービスとして申し込むとiD専用のFelicaカードが送られてきたりするから、そういうイメージで、追加サービスのカードのハードウェア部分が、たまたまAndroidのハードウェアになっているだけなんだろう。

ApplePayの説明だと、MasterCardとかJCBとか(VISAはない)の国際ブランドが並んでいるから、ぱっと見ると、iDを申し込んでなくてもいいように見える。なのでiDという仕組みがたまたま使える、ApplePayっていうイメージ。

ただややこしいことに、MasterCardは、MasterCardコンタクトレスというFelicaではないNFCを使う非接触型決済サービスを出してて、これがなかなか広まらなかったのだけど、iDでこのサービスが使えるようになってたりするから、表向きiDにみえて中はMasterCardのサービスとかの流れとかあるのかもしれないから、そういうことができる国際ブランドが並んでいるのかもしれない。業界のことなんか知らないから、わかんない。

とはいえ、ぱっと見では、クレジットカード会社にiDの申し込みをしてそれを登録っていう感じではなく、国際ブランドの手元のカードをiD支払いに紐付ければ、あとはAppleが適当によろしく処理してくれるのかな? と思える。これは大きな違いだと思う。おサイフケータイは、カードというハードウェアをAndroidというハードウェアに置換するだけ。ApplePayは、決済インフラにiDが選べるだけ、みたいな。

座組を想像すると

ApplePayは、どんな座組になっているのだろうか。クレジットカード決済は、ブランド-カード発行会社-加盟店管理業者、の3つの役割がある。iPhoneがカードの役割を果たすとすれば、Appleは決済の事業を持たない製造販売の会社だから、取りうる組み方は:

  • (ApplePay)-加盟店管理業者
  • ブランド-(ApplePay)-加盟店管理業者
  • ブランド-(ApplePay)

の3つの組み方になる。実際にはカード発行会社のカードを登録して利用するので、ApplePayの裏側にカード発行会社がずらっと並ぶ形になるから、それを乱暴にApplePayとまとめるのは間違いなのだろう。だから、これを書き直すと:

  • 座組としては: ブランド-カード発行会社-(ApplePay)-加盟店管理業者
  • 利用者から見ると: ブランド-ApplePay-加盟店管理業者

と視点ごとに区別して書けばいいのだろう。

Androidのおサイフケータイでは、iDのブランドで発行されたカードを登録する、Androidがカードエミュレータになるハードウェアであるだけ。それならばAndroid端末を製造する会社は、iDカードをエミュレートするハードウェアを製造すればいいだけだから、何も考える必要はない。だからカードがAndroidになるだけで、ユーザ体験も何も変わらない。

ApplePayの組み方は、カード発行会社と利用者の間に、強引に割り込んだ感じに見える。だから、カード発行会社であれば手にできる手数料は取れない。

カード発行会社とiDとの間の支払いをつなぐために、支払い期間のズレの吸収などで、それなりのお金をプールしなければならないだろうから、そのプールしなければならないお金を運用すれば得られただろう最低限の利益が確保できる程度に、とても薄い手数料を受け取る契約を、カード発行会社と結ぶくらいだろう。

支払い手数料を受け取れるカード発行会社は、顧客確保のためにポイントをつけるなどで、利用者を囲い込む。しかしApple自体は、薄い手数料しかとれないから、ポイントをつける原資がない。だがApplePay自体がiPhoneというハードウェアと結びついているから、iPhoneが売れることで利益が得られる。

これまで金融のなかで、3つの役割が成り立っていたところに、その役割を食う形で参入するのは、既存勢力から一斉に攻撃されておよそ無理に思えるけれども、この無理な割り込みの形は、そもそも利益源と顧客確保の方法が異なる4つ目の立場として、成り立っちゃったのでしょうか?

インバウンドとか狙うならiDと国際ブランド連携っていいと思う

SuicaもiDも、日本では便利かもしれないけれども、日本でしか便利ではない。そのうえ東京にいくと駅自体がSuicaに最適化されすぎて改札にICカード専用が増えている。東京に住んでいる人には便利だが、短期間滞在だと不便というのは、海外から来た人を排除する力だろう。

ApplePayで、ちょっと滞在したときに、滞在国のローカルサービスをちょこっと使えるのは、インバウンド、つまり、海外から来た人が消費をする、国内で消費しているけど輸出相当の消費、のために不可欠なピースだろう。

Suica程度なら使い捨てでカードを買うのはありだけど、あれはJR東のViewカードからしかチャージができない。クレジットカードからチャージする方法がない。だから日本円を手にして駅にある端末でチャージとか、およそ原始的な方法しかない。あるいはiD使いたくても、日本ローカルなカード発行会社からiDの付帯で個別カード発行とか、短期滞在でありえないでしょう。どっちも、ありえない不便さだろう。

SuicaにしろiDなんて日本どローカルなサービスを、カード発行しないと使えませんとか、東京オリンピックの招致のアピールで、”お・も・て・な・し”を口にしていながら、お金を使っていただく方々に対して、この国のルールに従え、なんて上から目線は、ありえないと思うわけで。

なので、手元カードとiDを紐付けられるのであれば、とても良い感じだと思う。というかApplePayの立ち位置こそ自然で、その国で事業をしているカード発行会社が絡む形のほうが、不自然に見える。

まだ発売前で、じつは海外から来た人は使えません、かもしれないし、その辺りが自然かどうかはわからないけど、インバウンドをテーマにするなら、Androidのおサイフケータイには絶望しかないけど、ApplePayにはこの先への希望があると思える。

Suicaのカード取り込みはすごいと思う

ApplePayは、手持ちのSuicaカードを残金情報を引き継いてそのままiPhoneに取り込めるらしい。しかもカードのデポジット代金500円がその時に返却されるらしい。さらに定期券などの情報も引き込める。まるでモバイルSuicaだけど、モバイルSuicaをiPhoneに持ってきたのじゃないっぽい。モバイルSuicaのだと年会費1000円(JR東の子会社のブランド、ビューカードと連携させていたら今のところ年会費不要だけど)がかかるけど、ApplePayにはそういうのはないらしい。

もともとJRのSuicaは、将来どのような異種のシステムが接続するかも予測ができない、ことを前提に作られている。異種統合型情報サービスシステムにおける自律分散アシュアランス技術、というやつ。

カード単体で情報を保持する、しかも駅を超高速でパスできるFelicaは、そのシステムの要の技術になる。カードの偽造や情報の書き換えが、カードそれ自体のハードと通信技術で厳重に確保されているから、もしも課金データを撮りそこねた場合は、Felicaカードの情報をマザーとする、というシンプルな方針が取れる。

その要なカードをiPhoneに取り込める、というのだから、驚く。それはiPhoneそれ自体がFelicaカードと同じセキュリティなどの技術で守られているとJR東が認めた、ということなのだろう。

しかも、iPhoneを落としても、リモートでiPhoneのひも付けを削除すれば、その端末に紐付いていたSuicaの情報を、新しい端末に繋ぎ変えられるらしい。Suicaのカードは常に1枚しかない、という前提があるが、iCloudはその常に1枚しかない状態を確実に保証できるほどJR東に認められているのだろう。いろいろ、大したものだなとおもう。

こんなの、JR東と協業しないと絶対に実現できないけど、ちゃんと協業しているのだなと、その取組はすごいなと思う。でもiPhoneからすれば、今まで自然にやってきたことを、今回もちゃんとやっているだけかもしれない。

この取り組みはしかし、携帯業界でも同じことをしてきた

もともと電話機を手がけていないAppleがiPhoneを出した時の座組を想像すると、決済は ブランド-カード発行会社-加盟店管理業者 だけど、携帯業界も、通信インフラ-SIMカード発行と代金回収-代理店 と3つの役割がある。

通信技術それ自体が3GそしてLTEとどんどん進歩していた。どんどん進歩する技術とちゃんと相互運用ができる携帯端末をちゃんと販売しなければならないから、キャリアが販売する端末を決められた。だから端末の販売代金を手にできた。技術が進歩している時は、技術開発と基地局の整備に莫大な投資が必要で、それを回収するためにも、端末販売代金は大切な収益源になる。

i-modeの時代は、ドコモが最初から課金と料金回収の決済システムであり、サービスを提供する奇妙なカスタムが入った独自HTMLライク技術を端末横串で一斉に搭載させるために、東京で閉じこもって、直接やりあって、すりあわせる。通信インフラと決済そしてサービスに端末のアプリの基盤技術仕様決定、全て握れていたのだから、文字通り、王様。

でも、技術それ自体が成熟すると。変な囲い込みをしかける。新規性にかける。陳腐化、ガラケー化。

そこにiPhoneという海外からの端末が登場した。普通なら割り込む余地がないけれども、顧客数を伸ばしたいソフトバンクは独占の形でiPhoneを取り入れ、急速に成長した。iPhoneはアプリやアプリ内課金のプラットホームでもあるから、i-modeから課金プラットホームでもあったドコモは最後までiPhone販売をしなかったが、そのドコモも今はiPhoneを売っている。

もともと割り込む余地が無いような業界のがっちりした枠組みの中で、うまく4つ目の役割で入り込み、課金という重要なプラットホームとしての立場すら手に入れたのが今のiPhone。

いまの3大キャリアは、売上自体は右肩上がりをしないと会社の評価が下がるから、パケット代金はそのままに、でも高額な月額を、iPhoneを販売してそこに割引をつけて、実質の月額で補っている。形のないパケットの量で商売をするための、さじ加減をつける材料にiPhoneの販売金額が使われている。

莫大な初期投資が必要な時期ならそれは社会に必要だったのだろうけれども、投資が一段落したならば、それで儲け続けてもらっても、社会はあまりうれしくない。そのお金が別の分野に使われて、違う分野が隆盛してほしい。それに電波資源という公共の財産を使いながら、事業的に独占の立場を占めるのは許されないことだから、回線部分だけを切り出してMVNOとかが隆盛してくるようにする。これでやっと、本来の 通信インフラ-SIMカード発行と代金回収-代理店 の3つの役割を、今まで前2つが1つの会社で牛耳っていたのが、3つの個別の会社に担わせることができる。

カードというハードウェアとのさようなら

クレジットカードのカード番号や有効期限あるいはセキュリティコードまで、全部の情報が磁気テープに入っているから、スキミングをしてコピーをするのは容易で、セキュリティなんてどこにもない。

でも、アニメ調の柄のクレジットカードだと、海外だと怪しんで受け取ってくれないとか、通信回線がない奥地にいくと、クレジットカードの上にカーボン紙を置いてローラーをがーっと走らせて転写する方式で、最近のNFCとIC化されたクレジットカードは回路を壊すからエンボス加工がなくて受け付けてくれないとか、けっこう末端の人だよりでセキュリティ的な対応をしている。

考えてみれば、クレジットカードは番号とかのアカウント情報を記載しているただのカードで、署名をして初めて支払いが成立するものなのに、怪しい柄だからとか、ローラーで転写できないから受け付けられないとか、逆にありえない。ローラー転写できなくても、手書きで書き写せば同じことだと思うし、今時エンボス加工のカードは3Dスキャナとプリンタで即座に物理コピーできそうだけど、そういうものでもないらしい。

クレジットの信頼を付与されているのは自分のはずなのに、紙と鉛筆の世界では、クレジットカードという形あるものでクレジットを表現しちゃっていたから、いつのまにか、クレジットカード=クレジットと、思い込みがあるような気がする。

最近のクレジットカードは、ICカード化とか顔写真を入れられるとか、いろいろとセキュリティを高められますとか提案してくるけど、紛失しても補償されるから、カード発行会社には利得があるのだろうけど、利用者にとってのメリットはない。

出張をしていると、クレジットカードをもしもなくしたらと思うと、けっこう怖い。なくして不正利用されても、紛失をカード発行会社に届けた日から遡って60日以内は補償されるから、その意味での怖さはまったくないけど、出張先で支払手段をなくすとか命の危機を感じるので、それが怖い。

iPhoneにクレカ登録だと、クレカとかなくしても、どこかでiPhoneを手に入れて自分のアカウントを入れれば、クレカが復活するのだから、そういう怖さから開放されそうで、それはいいなと思う。カードというハードウェアを離れて、本当に自分が持っている信用、クレジットで支払いができるようになると。

だから、出張先でもしもiPhoneをなくしても、どこかでiPhoneを買ってアカウントを登録すれば、支払い能力が復活する、カードという物理が、iCloudの私のアカウントにひも付けされて形ない情報に変換できる、そこがいいなと思う。

いまのATMは、カードを差し込んで使うから、iPhoneの中にあるクレジットだと現金を手にすることはできないけど、スマートフォンだけでATMからお金を引き出す、クレジットカードのハードが消えて情報化する流れがあるから、落として困るクレジットカードは、少なくとも都市部では、急速に消えるだろう。

うだうだ書きましたが

長々書きましたが、クレジットカードというハードウェアを正しくゴミにした、って気がします。本来、私に付与されているクレジット、信用をネットのアカウントに紐付ける、その紐付いた信用はiPhoneを通じて支払い相手に示せる。

iOS10雑感

はじめに

WWDC2016の動画から、iOS10への雑感をまとめます。

WWDC2016のここを見る

  • ロック画面のスライドバーがなくなり、ホームボタンの押し込みに変更された。
  • WatchOS3の登場、iCloudへのアクセスやジャイロなどのセンサーへのアクセスなど、単体での動作がほぼできるように。
  • SiriKitを通じて、タクシーを呼ぶ、メッセージを送る等の用途を限定して、アプリにSiriが開放。
  • CarKitのプレゼンがあった。
  • VoIPアプリに電話の発呼を開放するCallKit。

豊かなロック画面、アプリケーションのサービスの集約点

ロック画面のスライドバーがなくなり、ホームボタンの押し込みに変更されています。ホーム画面の左右スクロールは、通知画面やカメラ画面への移動となっています。またSiriKitを通じて、タクシーを呼ぶ、メッセージを送るなどの限定された範囲でSiriの機能がアプリに公開されました。またよりリッチな通知表示が可能となりました。

これを見ると、もうアプリを探して起動するすることは、手間で嫌なことになり、ホーム画面で日常の要件はほぼ完了するのが当然になると思います。この流れは、操作にアプリ画面を見る必要が無いならば、Watchに自然に体験が広がってもいくでしょう。

今までの電子手帳のイメージ、画像やテキストが表示されて、それを見て、タッチやテキスト入力の操作をする、そういった前提が変わります。

SiriKitの提供

iOS10では、SiriKitを通じて、タクシーを呼ぶ、メッセージを送るなど用途は限定されていますが、アプリケーションにSiriが開放されました。音声でサービスを呼び出す体験は、周囲に人がいて奇異に見られないならば、便利な体験です。アプリケーションを使う場合とSiriを使う場合では:

  • ホームボタンを押す → アプリケーションを探して起動する → アプリに条件を入力して検索する → 結果を目で見て選択する
  • Hey, Siri、タクシーを呼んでという → いくつかのサービス候補を選んでタッチ

と、手間と頭をつかう回数が少なく、操作完了までの時間も短く、今までのモバイル体験とは別の体験になります。

iOS9までは、アプリケーションの豊かさが、iPhoneをより便利により豊かな体験にしてきました。より多くの人が使うプラットホームが、より多くのアプリケーション販売収益をもたらし、それがより多くのアプリケーション開発をよびよせる、正のフィードバックをもたらしていました。

アプリからサービスのプラットホームへ

いままでのエコシステムはアプリケーションの豊かさでしたが、もうモバイル機器があることが当然になると、ユーザが求めるのはサービスです。そしてサービス事業者は、必ずiOSとAndroidの常に両方にアプリケーションを提供します。社会の様々なサービスがモバイルを通じて提供される時代には、サービス1stの時代には、モバイルのプラットホーム事業者の立場と役割が変化します。

これまで写真や音楽といった自社サービスと豊かなアプリケーションの世界は次の時代に切り替わろうとしています。例えば、音楽というコンテンツを販売するiTunesは、ユーザが楽曲を買えば買うほど、楽曲を楽しむためにiTunesを使い続ける強い理由になりました。しかし音楽は月額定額で配信で楽しむ時代になってしまうと、購入したコンテンツを理由にしたユーザの囲い込みは、その根底から崩れます。

モバイルのプラットホームはAppleとGoogleのほぼ2強ですが、より便利で自然なサービス体験を提供する方にユーザは流れます。音楽や写真がたまっているから、iPhoneを使い続ける、という囲い込みの理由がなくなれば、ユーザは携帯電話を買い換えるたびに、iOSとAndroidを自由に比較して、気軽に切り替えるかもしれません。

ハードウエアの販売が大きな売上と利益をもたらすAppleにとっては、死活問題にもつながります。

より豊かで便利なサービスを提供するプラットホームへと、大きく鍵を切り替えていかざるをえないのだろうと思います。Siriのアプリケーションへの開放は、ユーザがサービスを利用する手間を極限まで小さくする1つの仕組みとなるかもしれません。また、サービス事業者はアプリのSiri対応をしなければならないでしょう。

サービスと会社の協業

CarKitは車載AV機器との連携を提供します。その仕組はiPhone側から画像を表示する仕組みと、車載機器側からはタッチされた(x,y)座標をiPhoneに返す程度の、とてもシンプルな仕組みです。実装には手間はかからないでしょうし、車載AV機器それ自体の価値を強制的に横取りするようなものでもありません。

CallKitはVoIPアプリにiPhoneの通常の電話体験を開放するものです。VoIPでかかってきた電話が、CallKitを通じて、通常のiPhoneの電話UIへとつながります。LINEなどのサービスはもちろん、内線電話アプリなどのビジネス向けのサービス開発に役立ちそうです。

アプリケーションによるエコシステムであれば、Appleが新たな機能を提供することで、新たなアプリが開発販売されて、それがiPhoneの魅力となり、アプリそしてiPhoneの売上という収益源になりました。しかしVoIPアプリで、サービス利用をアプリ内決済に限定することは困難でしょう。CallKitを提供しても、Appleはこれまでのエコシステムのような収益が得られるとは、限りません。

しかし、例えばビジネス向けのサービスに採用されれば、iPhoneという端末は売れ続けます。逆に、Androidがビジネス向けで他社が使いやすい何かを提供してそのような立場を占めてしまえば、一旦採用された分野に後から潜りこむことはビジネス用途ではかなり大変ですから、売上のチャンスを手にできなくなるでしょう。

BLE4.2勉強会に参加して

BLE4.2勉強会でのプレゼンテーション

BLE4.2勉強会 Maker Lab Nagoya に呼んでいただき、以下の資料でプレゼンをしていました。

参加された方々は、初めての方や、2013年にあったBLEの講演や2014年に大垣で開催されたiBeaconハッカソンに参加されたお久しぶりの方々で、 また名古屋以外から多く来られていました。

iOSと家電を統合するHomeKitというものがあるのですが、ラズペリーパイやESP8266などにホームキットを実装して、 Siriに”リビングは何度?”と温度を聞いたり、”照明をつけて”と指示を出したり、もう会話が成り立つレベルで使えること、 またその作ったものを見せていただくなどしました。

本音では、あんたらプロやん、むっちゃプロやん、っていうか知識もうあるやん勉強会とか必要ないやん、と心のなかではツッコミまくりです。

プレゼンの構成と内容

プレゼンの構成と内容は、すでにBLEをよく知っている方々と、基礎から知りたい方々のどちらにも役に立つものをと考えました。 前半はBLEを、後半はBLEに限らず今バズワードとなっているIoT系も含めて広く、ハードウェアが持つ意味をどう変化させていくのか、 その自分なりの考え方をまとめました。

BLE4.2の使い方、使われ方

BLEの内容は、2013年での講演のようにBLEの技術内容を物理層からボトムアップで詳細に語るのではなく、 その技術がどのような使われ方につながるのか、またその技術が世の中で使われるとどのような意味を帯びるのか、から構成しました。

ネットワーク・トポロジは、つながりかた、つまり通信で誰と誰が関われるか、その形を決めます。 4.0での単純なスター型でよい場面、また使えない場面。そして4.1で入った更新がもたらした変化を話しました。

パケットをやり取りするリンク層は、電池交換や商品価格や外形デザインに大きく影響する消費電力などに影響します。 ブロードキャスト、リンクした時の通信の特性を話しました。

Bluetoothは無線通信を通じてハードウェアを使うための技術と言ってもいいでしょう。通信を通じて、ハードウェアと関わるために ATTおよびGATT層が持つ役割を、20世紀ではなく21世紀でのオブジェクト指向という視点で話しました。

セキュリティ・マネージメントは、表には見えにくい技術ですが、ハードウェアがネットワークに繋がる時代には、 そのセキュリティ・マネージメントこそがハードウェアの所有や利用の権利を管理する重要な核となります。 通信技術の視点でのセキュリティ・マネージメントは、利用者の大切なプライバシーやセキュリティを守るための技術ですが、 そこにハードウェアが関わることで、権利のための基盤技術となり、大きな意味を持ちます。

L2CAP connection oriented channel は4.1で導入されたBLEでもL2CAPを直接ストリーミングとして使える仕組みです。IP系の技術などGATT/ATTとは全く生まれの違う技術でも、 GATT/ATTと共存させることができます。

無線通信は通信相手も同時に普及しなければならないために、通常は普及までに長い時間がかかります。BLEは、すでにほぼすべてのスマートホン に採用されているBluetoothの規格一部であるため、Bluetoothブランドのもとで、またiPhoneにより短期間のうちに普及しました。

直接電波をやりとする物理層は、金物でしか実現できませんから、このチャンネルのような仕組みがあると、 電波をやり取りする部分は、スマートホンから直接使える利点もあり大量に製造されることでコストも下がりますから、BLEでよいのではないかとも思えます。

IoT系の話

インターネットを振り返りIoTを見通す

IoTという単語が話題になってきています。その話題の単語について語るのは、例えば2000年にインターネットという単語で、これから生まれていくる 新しい企業やサービスを議論するような、いくつもの分野にまたがるとても広い範囲の話となり、何時間でも話が尽きないことになります。

しかしインターネットという単語は、たしかに新しいサービスを生み出していますが、世界の価値生産からみてそれなりの割合を占める 新しい産業を生み出したのかといえば、自分の生活を見る限りは疑問です。 しかし、新しい技術で市場に参入することで、大きなシェアを占めることは、いろいろなところで起きそうです。

例えば、私は、商品購入や移動あるいは宿泊は全てネットを経由して提供されるサービスを利用しています。 ネットがなかった2000年以前とネット経由でサービスを利用している2016年では、利用している会社あるいは業者は全く違っていますが、 しかし消費活動それ自体は同じものです。 しかし、インターネットあるいはITという新しい単語で、ネット経由の旅行業を始めた会社は大きく成長しています。 アマゾンなどの通信販売会社は年々売上を伸ばしています。

IoTという単語で新しい消費は確かに生まれているはずですが、しかし個人の消費行動が大きく変わらないなら、 世界の価値生産の大きな部分を占めることはありません。 産業としてみれば人の消費活動それ自体は新しい物はなく、しかし新しいものとしてラベリングされることで、新しい物を提供する会社が 既存の需要/シェアを飲み込み、急速に成長する気がします。

見せかけのオープン

IoTという単語で、いくつかの企業が集まり新しい規格や団体を作り出しています。あまりに多くありすぎて、もはや、どれがどれかを認識することすら困難です。

今の時代的には、それが実用に足るのかを判断できる程度に、1つの規格を見ていくのも時間と手間がかかります。さらに、通信技術が使われるためには 既存分野の枠を超えた広がりなど、周囲の盛り上がりが注目をあつめるために必要でもあります。

技術仕様がオープンであれば、オープンソースプロジェクトなどで、使いやすいものが出てくる可能性もあります。 また、規格団体がオープンソースでプロジェクトを運用することもできます。もしもオープンでなければ、 規格団体がプロジェクトを運用するときに自身のオープンにはしない方針に縛られて、バイナリファイルの形でしか提供できない、あるいは 個別問い合わせでライセンスを締結しなければならないなど、活動の活発さを削ぎ落とすことにしかなりません。

また、仕様がオープンであっても、収益源として確保する方法が、今はいくらもあります。 事業をするならばライセンスが必要になる法的なユーザライセンスにしておいてもいいでしょうし、 事業規模で実施するには認証コードや暗号鍵のようなものの払い出しをうけなければならないような技術的な方法もあるでしょう。

もしも規格が、本当にオープンなのか、それとも今時の時代の流れに合わせて横並びになるためにオープンにしているだけなのかを判別するならば、 個人あるいは従業員数名の会社でも、規格に対して提案ができる仕組みがあるのか、また提案が取り込まれる可能性があるのか、を見てみるのがいいかもしれません。

もしも、規格は公開されてオープンになっているが、規格を決める手順や運用は公開されていないならば、形はオープンではあるが、その意味は、 我々の軍門にくだれ、これは軍門にくだるための手順書だ、という斜めからの見方も、できるのかもしれません。

オープンの意味

2000年にインターネットという単語が話題になり、ウェブ制作会社など今までなかった会社が生まれる一方、インターネットを活用した今では大きな会社がいくつか生まれています。 そのような会社は、システムは会社の根幹ですから、会社内部でシステムを作っています。

一方で、2010年以降は、iPhoneのアプリ市場の盛り上がりなど、ハードウェアとSDKそしてアプリ配信と課金システムがプラットホームとなり、その上で多種多様なサービスが 展開されています。いわゆる、エコシステムと呼ばれるものですが、日本でも1つのアプリで何千億円もの売上をあげるソーシャルゲームが誕生しています。

そう見ると、IoTでのオープンというのも、プラットホームとしてのオープンさ、エコシステムになるための必然としてのオープンさなど、いろいろ違うオープンがあるのかなと思います。 これからIoTで事業をする会社が外注することは、ありえないでしょう。IT系の投資は、初期はせいぜい人件費、1桁億円でしょう。 金額のちいささと事業の将来を決めるものととらえる重要性をちゃんと理解するなら、内部で閉じたチームでお仕事をされるだろうな、そう思います。

IoT系の本当に社会で運用されるニュースが表に出てくるのは、おそらく8年後くらい、例えばアマゾンのシステムを利用しているところが、アマゾンの宣伝のために講演に出てくださいと 促されて表にでてくるなど、そういう感じかなと思います。

どんづまりの悪あがき

ニュースでIoTという単語を目にした時は、それをニュースに出すことが利益になるものがいないか、を考えてしまいます。

前節の旅行業界の変化の振り返りから、IoTという単語は便利な道具ではなく、消費や決算あるいは流通経路が今までとは違うものにしうる何かとも言えます。 誰しもがそういった可能性を現実に起きうるものと感じるからこそ、IoTという単語は話題を集めるのでしょうが。

既存の大企業が、5年間の中期経営計画を立てるとき、IoTという単語を使うのは、流通などの経路の変化とはお金の流れの変化であり、それは大変化ですから、それはそうなる気がします。 しかし、ビジネスモデルそれ自体は全く変えずにネットを活用していますと外部にアピールするようなものであれば、 それはIoTという単語をただの便利な道具と誤解しているだけか、未来的な単語を取り入れることで株価に期待値を織り込みたいだけか、 なのでしょう。

自分が変化する気がなくて、現状からさらなる成長を探す努力に疲れて、 一振りすれば業績が10倍になる魔法の道具の渇望からIoTという単語が口から出るなら、もうその会社は寿命を迎えているのでしょう。

雑談のなかから

ウェブとハードウェアのエンジニアの、混じらなさ

BLEの開発でも経験しますが、アプリはアプリの会社、ハード(とBLEのファームウェア)はハードの会社と発注先が別れることが、 よくあります。そうすると、アプリとハードのエンジニアの所属会社は別ですから、勤務場所も別となり、アプリとハードの連携部分で、 うまく動かない、こういうものではないと、トラブルしか起きません。

IoT系の分野でも、プロジェクトをちゃんとマネージメントできる人がいなければ、そういう事態になるしかないだろうなと思います。

受託案件をしていて思うのは、3という数字が大事だと思います。発注と受注という1対1の関係性では、意識して対等の関係であろうとしても、 どうしても納期あるいは仕様などで、対等になりにくい部分が無意識に意識されて、それが見えないトラブルの原因となりかねません。 そのようなとき、発注-受注の関係ではなく、第3者的に、普段は別に仕事をしているわけではないが、客観的に流れを見ていて、 ときどき関与する人が、いるといいのかなと思います。

MQTTとかCoAPとか

IoT系のデモンストレーションとして、MQTTを使って、1つのハードウェアのボタンを押すと、ネットワークで繋がった別のハードウェアのLEDが点灯するデモンストレーションが、 よく行われます。

2000年前半にIPv6振興で公的機関が動いていた時期があります。その当時はブラウザから機器を操作する、いわば回りくどいリモコンがデモンストレーションとしてよく見かけました。 現代にブラウザから機器をオン・オフしても、それはそうだよねとしか思えません。ハードウェアの連携という姿を表わすのに、このようなデモンストレーションになるのかと思います。

その時によく使われているのがMQTTというプロトコルです。ブラウザではない何かのデモンストレーションをするときに、ツボにはまるのだろうと思います。

ただ、デモンストレーションの都合というしょうもない発端を一度忘れてみると、MQTTの仕組みをデータによるシステムの疎結合の結合点としてみると、いわゆるIoT的なものを構築するときの 1つのパターンと見てもいいかもしれません。

例えば、Suicaのシステムを構築した方が博士論文を出されています。 異種統合型情報サービスシステムにおける自律分散アシュアランス技術の研究

Suicaといえば、駅だけでなく、いまやバスや売店など広い範囲で使われている、まさに支払い手段のインフラといっていいまで普及したブランドです。 このSuicaを支えるシステムは、毎日大量の利用/決済データを全国各地で処理するだけではなく、システムの一部が故障や停止をしても全体として停止しないタフさをもたせる、 また異種のシステムの接続を受け入れていく必要がでてくるだろうなど、設計時点では想定できない事態に対処できる柔軟さをもたせるなどの、 実用から必要であり、まただからおもしろいと見える、発想から設計されいる、っぽいです。

このシステムの技術的な根っこは、 システム要素がバスに流れるデータに反応するデータ駆動の疎結合、 データの矛盾が発生した場合はSuicaの電子カードの記録をオリジナルデータとする矛盾発生の対処方針、にあると私は思いました。

そう思うとMQTTは、システムが時間とともに成長し変化していく柔軟さを持たせるために不可欠な、構成要素間の疎結合と要素間の連携動作の連結点、電気回路でいえばバスのようなイメージのなにかを、 IPの世界で提供する何かと見ておくと、いいのかもしれません。

その他

オフレコでしか話せない内容を話せて、個人的には満足しました。

なぜきぐるみを着たのかという話、集団から異種な存在である立場の持つ意味、 ニュースで見かける東京というか秋葉原発のハードウェア・スタートアップの内容が個人的にむちゃくちゃ嫌いな理由、 IoT系にも通じるボケとツッコミの大切さ、ハードウェアそれ自体に価値がなくなっていく時代の流れなど、 リアル世界で肉声で話してみて、自分にとって大きな収穫を得られた気がします。

また今後共。

nRF52の印象

モジュールの種類と選定ポイント

各社からnRF52を搭載した無線モジュールが、評価版が1月から2月、量産が3月から4月に開始される予定です。nRF52はnRF51とピンコンパチブルなので、モジュール利用者から見れば、nRF51の無線モジュールをそのまま置換できるイメージでよいでしょう。無線モジュール開発会社にとっては、バランがオンチップになったりと高周波周りは再設計で手間がかかるとは思いますが、それが仕事ですから、作ってくるだけの話だと思います。

モジュールは、大きさで2種類に分類できます。一つは10x13mmくらいのもの、もう1つは11x5mmあるいは更に薄く小さくしたものです。nRF52は、6×6mm QFN と小型の3.0×3.2mm CSPの2種類のパッケージで提供されます。小さいモジュールはCSPを使っていたりします。

10mm角程度のモジュールは、汎用的に作られているものです。nRF52のすべてのIO端子が外部に取り出されている、たいていの場合ではDC/DCの外付け部品と32kHzの発振素子がモジュール内部にあります。小さいモジュールは、ものによりますが、すべてのIO端子は取り出されていない、DC/DCおよび32kHzの部品が省略されていることがあります。

モジュールを選ぶときには、極端に消費電力を気にするのか、IO端子はどれだけ必要か、の2点で決めればよいです。大きさが制約条件になる場合は、小さなモジュールでならば実装できるとしても、技術的には、独自に実装してしまったほうが早いかもしれません。ただし開発費用が1000万円ほど上乗せになりますから、そのあたりは技術ではない選択になるでしょう。

BLEで電池を使うものは、使い捨てのCR2032などのコイン型電池あるいは充電可能な40mAh程度のリチウムイオン電池を使うでしょう。コイン型電池で直径16mmか20mm、リチウムイオン電池でもその程度の大きさなので、腕に巻く細いバンドでもない限り、どちらの大きさのモジュールでも使えるくらいです。

消費電力を気にする場合は、DC/DCは必須です。(32kHzの発振素子もあったほうが、たぶんよい。nRF51の場合では、32kHzの発振素子がない場合は平均4マイクロアンペア程度消費電流が増えます。nRF52でそれがどうなるかは未確認ですが、増えるんじゃないかしらん?)

nRF51からnRF52へ移行すべきか

nRF51を使っている既存製品の次モデルをnRF52にしておくとメリットがあるのか、あるいは新規開発でnRF51とnRF52を選ぶとすれば、何を基準に判断すればよいのか、いろいろあると思います。

nRF51それ自体は今後も提供されていくでしょう。ですが特にnRF51を選ぶ理由がないならnRF52を選んでおくのがいいと思います。

nRF52はnRF51と内部構造は同じです。またパッケージはピンコンパチブルです。ファームウェアやSDKあるいはソフトウェア・スタックなどのソフトウェアのバージョンの違いは出てきますが、nRF52はnRF51の上位版として使えます。

極端に消費電力を気にする場面では、採用する価値が大いにあります。

これは無線回路の低消費電力化もさることながら、周辺回路のPPIおよびEasyDMAの活用が可能になったことがあります。逆に、それらの機能をファームウェアが活用しないならば、nRF52の価値はないです。機能を達成するためには、ハードウェアの選定時には、その旨を共有するために、ファームウェア開発者も同席させておくべきです。

nRF52から見えるファーム開発手法

nRF51でもそうでしたが、nRF52ではさらに、ハードウェアっぽい開発のやり方が適していると思います。1つはRAMの使い方、もう1つは周辺回路のリソースです。

ヒープ領域つまり動的に確保解放するメモリ領域は、BLEでは使う必要はないと思います。nRF51のSDKを見ると、例えばタイマーなどは、必要なタイマーの数をコンパイル時に指定してしてしまいます。1つ1つの機能が必要とするRAM領域を静的に確保し、使い続ける感じです。

これはアプリケーションが使えるRAMサイズが8kBもしくは24kBのnRF51だったから、そういうコードを書いていただけで、RAMが64kBになったnRF52では、ヒープ領域を活用すればいいだけかもしれません。

ヒープは、処理を時間軸で見た時に、処理が開始/終了する場合に、メモリ領域の確保と解放によって、小さなメモリでも処理を収めることができます。ある処理について、処理時に必要なメモリ量がかなりあるとします。しかし、処理が終わればメモリは解放できるとします。そんな処理を、1つ1つ処理していくならば、ヒープ領域を使うべきです。

ですが、BLEのハードウェアは、電源が入ってからずっと、それぞれの機能自体が最初からずっと動き続けるものがほとんどです。ソフトウェア処理であっても、とてもハードウェア的です。このようなものは静的メモリ確保がよいです。メモリが不足して処理が停止することがないか、というワースト・ケースの検証がむちゃくちゃやりやすくなります。

この方法では、メモリ不足の例外が生じた時には、動的に確保されるのはスタックを見るだけでよいです。スタックは処理順番と処理過程の情報を全て含みますし、静的に機能しているものは静的なメモリ領域を見ればよいので、例外発生時のデバッグが楽です。

極端な話をすれば、動的なメモリ確保では、メモリダンプをしても、どこにどんな値があるのかを読み取るのは、とても大変です。静的な割当であれば、シンボルテーブルを見ながら人力ですら、目視デバッグ可能です。

nRF52は周辺回路すべてにEasyDMAが入りました。nRF51でのPPIは、タイマーやGPIOを組み合わせて一定周波数のパルス波形を出す程度にしか、活用できませんでした。しかしメモリ転送が組み合わせられるので、TWI経由でのデータ収集がPPIとEasyDMAでできます。

if then elseが入らないかぎり、また演算処理をしないかぎり、プロセッサを起動する必要はないでしょう。またデータをためてから一気に処理をすることで、プロセッサのスタートアップ時間40マイクロ秒で消費する電力を最小化できるでしょう。

通常であれば、プロセッサが制御を行うもので、周辺回路は割り込みでプロセッサに処理を委譲するファームウェアを書くと思います。nRF52でも、電力を気にしないならば、普通のそのようなファームウェアは書けますし、それで機能します。

nRF52であればできること

nRF51ではできなかったがnRF52であればできることは、デジタル信号処理が必須になる利用場面です。音声のやり取り、音の送受信、また万歩計などライフログ的な機能などがあります。

例えば万歩計であれば、3軸加速度データを1000サンプル/秒で収集、合計3kB程度のデータを貯めて1秒ごとに一気に演算処理する、なんてことができます。プロセッサがスリープから起動する40マイクロ秒よりも、演算処理時間が十分に長く取れる程度に、IOをバッファリングさせることがnRF52なら、可能です。

IoTの話題

IoT系の話題に乗りたいなら、nRF52を採用すべきです。今後、IoTに向けた規格拡張がなされていきますが、nRF52はそれらに最適な対応ができるハードウェアに、たぶん、なっています。

IoT系の話題が盛り上がっています。BLEでも、IoT系で必要になるメッシュネットワークに必要な技術を提供しています。また今後のBluetooth規格には、メッシュネットワークが規格もしくは実装推奨など何らかの形で、SIGからの提供があるでしょう。

IoT系でのBLEの立ち位置は、2.4GHzで電池持ちがやたらといい超低消費電力無線通信技術で、スマートフォンやパソコンが通信相手になれる普及した無線通信技術です。

920MHzのように100メートルを超える距離の通信や、Zigbeeなどのメッシュネットワークを始めとした工業用途での実績はありませんが、スマフォが対応している1点だけでも、一般消費者に使いやすさを提供できる技術です。

隣のBLEデバイスとの通信の確保、つながったデバイスがパケットを中継して、遠く離れたデバイスにパケットを届けるくらいまでは、技術が提供されるかもしれません。しかし、WiFiなど他のIoT系と同じく、通信スタックをどうするか、デバイスの管理機構やそのための通信仕様、あるいはデバイスのデータ表現の方式などは、標準規格が乱立していきます。

このあたりは、BLEとしては、上層には何を採用してもプロセッサにその処理を実装すれば作れます。何をどうするかは、ハードウェアの製造会社が決めれば良いだけの話です。

雑感:BLEだけでよいのだろうか?

nRF52に限らずnRF51でも成り立つ話なのですが、複数のBLEデバイスが身の回りにあふれる状況で、BLEだけでよいのだろうか?、と思うことがあります。IoTやスマートホームの話題にかぎらず、身の回りにわんさとデバイスがある場面であれば、1台ごとにユーザが管理するのは、ユーザ体験として無理があります。

そのときに、開発としては、メッシュネットワークやIoTの標準技術になるだろうIPv6などの通信技術や規格を求めたくなるかもしれません。しかし、通信技術とは通信相手があって初めて意味がある技術です。身の回りにあふれるデバイスとの通信相手は、なんでしょうか? 必ず、WiFiに接続する何らかのデバイスあるいはスマートフォンがルータになります。このルータと複数のデバイス間はBLEしかありえません。しかし、デバイス間がBLEである必然性はあるのでしょうか?

またIPv6が規格としてかたまり利用可能になったとしても、デバイス管理システムは、おそらく自社で構築する他ないでしょう。これはIPという技術は通信を提供するだけで、その上のアプリケーション、管理システムにはまったく関わらないからです。おそらく、会社ごとの管理システムが乱立して、誰も使わない暗闇の時代になるでしょう。

IPv6でBLEデバイスが直接インターネットに繋がることは、デバイス管理上、ありえないと思います。家庭用のWiFiを見ていても、防壁がなければいろいろなところからちょっかいをかけてくるのがわかります。BLEデバイスであれば、通信はすなわち電池の消費に繋がる場面もあります。セキュリティの意味でも、BLEを直接外部の任意の通信にさらしてもしかたないです。インターネットとBLEの間にあるルータには、フィルタリング機能が入るでしょう。

では、デバイス間では? BLEをベースにしたメッシュネットワークなど、これから実現される技術を使っても良いのですが、自社製品だけで固めるならば、独自の技術でも良いはずです。nRF51およびnRF52には、Time Slot APIという、BLEが無線回路を使っていない間、無線回路を使うAPIがあり、任意の通信プロトコルが実装可能です。そういったAPIを活用して、BLEに準拠しない自社で閉じた通信で、デバイス間連携と管理システムを作ってしまうのでよいのでは、そう思います。

また、技術が標準化されたならば、ファームウェアを更新することで、その技術への対応がnRF51/52であれば、できます。そういう進め方で、いいようなきがするのです。

nRF52 Global Tech Tour 2015 に参加してきました

nRF52 Global Tech Tour 2015 Nordic Semiconductor は、Nordic Semiconductor社のBluetooth Low EnergyシングルモードチップnRF52の開発者向けイベントです。

世界各国で開催されていますが、日本では12月8日に東京そして12月10日に大阪で開催されます。東京 六本木ヒルズでの回に参加してきたので、レポートします。

ツアーの雰囲気や飲食

ツアーに参加すると最後に、9500円位するnRF52版開発ボードが参加者全員にプレゼントされました。各国の電波法の適用は受けていないので、外部に電波が出てしまわないようにシールドボックス内部などで使う必要がありますが、太っ腹です。

会場や集まった方々の雰囲気

場所は アカデミーヒルズ でした。360席ほどある会場が満員でした。 周りをざっと見渡すと、年齢は30代から50代、9割位の方がスーツ、またほとんど9割以上が男性でした。 日本の電気工学系の学部は、女性比率が2%程度だったりするので、こうなってしまうのだろうと思います。

プレゼンテーションは英語ですが、日本語の同時通訳が提供されていました。質疑応答も通訳の方がサポートしてくれるので、日本語で大丈夫でした。 同時通訳のイヤホンを使われている方は、見渡すと1割くらいで、普通に英語に慣れている方ばかりなのだな(大手電機メーカの方もきっと多いと思うので、それが当然なのかもしれませんが) と思いました。

フロアにあるお手洗いは1つで、男性12人程度で一杯になるもので、休憩のたびに少し行列ができていました。私は出口付近の席にいたので、いの一番に外に出られたので、並ばなくてすみました。座る場所は指定されず、どこでもよいので、早めに出かけて場所を確保しておくのが、いいのかもしれません。

飲食など

お昼にはお弁当が出ました。

会場の直ぐ側には、飲み物とお菓子がたくさんありました。 紅茶、コーヒー、ペットボトルの水、そしてマフィンのようなお菓子が常に補充されていました。紅茶ばかり頂いていましたが、美味しい紅茶でした。

スライド抜粋

nRF52の概要

nRF52シリーズは、Nordic Semiconductor社にとって第3世代となるBluetooth Smart Socです。

nRF51シリーズは、2.4GHz帯の汎用無線回路と周辺回路そしてプロセッサを組み合わせて、通信処理をプロセッサに担わせることで規格の機能追加に柔軟に対応できる構成をとっています。

nRF52でも、その構成はnRF51と同じです。プロセッサの処理能力を高めフラッシュおよびRAM容量を増加、電源制御や周辺回路の数や能力を強化、そしてNFCを搭載しています。

nRF51はBluetooth 4.0までの無線通信技術に対して最適化されている感じがします。

nRF52は、Bluetooth4.2で追加されたセキュリティおよびIoTに向けた機能、また今後のBlueototh無線通信技術に追加されていくかもしれない、通信の高速化、音情報のやりとり、またIoTに向けたネットワーク技術への対応などに対応できる構成となっています。

プレゼンの構成

セミナーの流れとその雰囲気は、 nRF52 セミナー のまとめ がよくまとまっています。とくに@ksksueさんの一連のTWは、詳細までまとまっていて、素晴らしいです。

セミナーの資料は当日ダウンロード配布されていました。セミナーで配布された資料全体を不特定多数に勝手に配布したりするのは、やめてくれという話でしたが、ブログで技術紹介をするときに、スライドの一部を参照するのはできるっぽいらしいので、このブログでは必要な部分を掲載しています。

全体のプレゼンテーションは、半導体のハードウェア構成、その特徴と活用のポイント、そしてソフトウェア・スタックやSDKのファームウェア・開発、そしてIoT系の話題で構成されていました。また最後に、日本のモジュール・メーカ各社(太陽誘電、富士通、ブレイブリッジ、ホシデン)から、nRF52の無線モジュールについてのプレゼンテーションがありました。

プレゼンテーションは、ほとんどがハードウェアよりの内容でした。BLEは2015年時点では、スマートフォンと連携するハードウェアによく使われています。ですから、スマートフォンおよびそのアプリケーションとの連携や開発情報は重要だと思うのですが、そういったものは今回はカバーされていませんでした。その代わり、2015年はいろいろなところで話題にされたIoTについて、1セッションが取られていました。

プロセッサとその周辺

  • プロセッサの処理能力の強化
  • EasyDMAとPPIを組み合わせたプロセッサを使わずに済む仕組み
  • スリープ時の消費電流をより低減

などが特徴です。

処理能力の強化

nRF52は、デジタル信号制御市場向けに開発されたARM社のプロセッサCortex-M4Fをコアに採用しています。

Cortex-M4自体、デジタル信号処理に適した命令が追加されてDSP機能が強化されています。Cortex-M4Fは、Cortex-M4に、さらに32ビットの単精度浮動小数点ユニットというハードウェアを追加したものです。

nRF52の動作周波数は 64MHz RAM 64 kByte フラッシュROM 512 kByte です。

nRF51は、Cortex-M0 で、動作周波数 16MHz、 RAM 16 kB または 32kB、 フラッシュROM 128 kB または 256 kB です。

nRF52はnRF51よりも、単純にクロックで4倍、また浮動小数点演算は専用の演算回路がハードウェアであるため10倍ほどの演算能力があります。

プロセッサを使わずに済む仕組み

nRF52は、nRF51にもあったPPIおよびEasyDMAという2つの機能を強化して、プロセッサがスリープしたままでも、例えばTWIで接続された加速度センサーから一定周期でデータを読み込む、ような処理ができます。

PPIはnRF51からある機能です。これは周辺回路にあるイベントとタスクを、ソフトウェアで結びつけて、周辺回路を組み合わせた機能を実現するものです。

例えば、パルス幅変調信号を生成したいとします。

PPIでは、周辺回路にはイベントとタスクという概念があります。

TIMERには、オーバフローやカウント値が設定値と同じになった等の、いくつかのイベントがあります。またTIMERには、カウント値をカウントアップする、または0クリアする等のタスクがあります。

TIMERの、カウント値が設定値と同じになったイベントを、カウント値を0クリアするタスクに、プログラムで結びつけるように設定します。こうすると、カウント値ごとにイベントが発生させられます。

また、汎用IOであるGPIOTEには、出力値をトグルするタスクがあります。先ほどのTIMERのイベントを、このトグルするタスクにも結びつけましょう。すると、一定期間ごとにGPIOの出力がトグルする、つまりカウント値で指定した期間の2倍のパルスが出力できます。

例にあげた、PWM信号の生成は、プロセッサではよく使われる機能です。ですから、一般にPWM信号を生成してGPIOから出力する機能は、マイコンメーカ各社がそれぞれ工夫してタイマー自体の機能として提供しています。nRF51およびnRF52は、これ以上シンプルにできないところまで機能を簡素にして、それらの機能をソフトウェアで組み合わせられるPPIという仕組みを使って、複雑で多種多様な機能を組み上げるというアプローチをとっています。

EasyDMAはnRF51でも採用されていましたが、無線回路やSPIスレーブなど一部の周辺回路のみにありました。nRF52では周辺回路全てにEasyDMAが入りました。

EasyDMAは、周辺回路が64kBのRAM領域に直接読み書きする機能です。例えば、TWI(いわゆるI2Cです)などのシリアル・インタフェースで加速度センサーの値を読みだす時に、プロセッサを起動することなく、TWIから設定されたRAM領域に直接データを書き込ませられます。

PPIとEasyDMAを組み合わせると、例えば、TWIで指定したメモリ領域から2バイトを出力(加速度センサーのアドレスと読み出し指示)して、3バイトを読み込みメモリポインタをインクリメントしつつRAMに書き込む、これを10回繰り返したら、プロセッサに割り込みをかける、といったシーケンスを組み立てられます。

このシーケンスの実行に一切プロセッサは必要ないので、プロセッサはスリープ状態、つまり電力を低減できるというわけです。

スリープ時の消費電流をより低減

nRF52には、スリープ時の消費電力も、より低減できる工夫が入っています。プロセッサのコア動作時の消費電力は、3V電源でDCDCが有効なとき3.3mAです。RTCが有効なアイドル時の消費電流が1.6マイクロアンペア、スリープから40マイクロ秒でスタートアップします。

また、RAMの値保持は、4kBごとに保持するしないが指定できて、保持する場合は4kBごとに40nAです。nRF51はRAM全体で保持する保持しないを指定できて、保持する場合の消費電力は1.2マイクロアンペアでした。

消費電流を極限まで低減したい場合に、ファームウェア開発者がよりハードウェアにより手が届くようになっています。電源がACアダプタなどであれば、マイクロアンペア程度の消費電流の増減が問題にはならないなら、そのような作り込みをする必要はまったくありませんが。

周辺回路

無線回路

無線回路の消費電流は、動作電圧3VでDCDCが有効なとき < 6mA です。送信電力が最大+4dBm、最小-20dBmに設定できるので、消費電流に幅がでます。

受信感度は-96dBm、nRF51が-93dBmですから2倍高感度化、またオンチップバランにより外付け部品は回路図上では2つにまで簡素化されます。

nRF51に対してnRF52は、受信時の消費電流を半減、送信時の消費電力を3割減となっています。この値はnRF52のオンチップDC/DCが有効な場合での値です。DC/DCを使わない構成をとった場合は、オンチップのLDOのみが使われます。この時、nRF51に対してnRF52の受信時消費電流は1割減、送信時消費電力は4パーセント増となります。

またオンザフライでパケットの暗号化/復号化、またペアリングした相手がランダムアドレスを使っている時に、そのアドレスを復号する機能が無線回路に入りました。

Bluetooth4.0では、ホワイトリストに指定できるアドレスは、パブリック・アドレスのみでした。Bluetooth4.2では、ランダム・アドレスも指定できます。

nRF51ではランダム・アドレスの解読はプロセッサで処理する他ありませんでした。これが無線回路で処理されるので、消費電力を増やすことなく、Bluetooth4.2で追加されたホワイトリストの機能が活用できます。

またIoTなどの通信では、パケットの暗号化/復号化は常に使われる機能となっていくでしょう。そのような処理を無線回路で行うことは、消費電力低減に役立ちそうです。

電源回路

nRF51はDC/DCを使う/使わないで、外部配線が異なりました。nRF52はDC/DCに必要なコイルとコンデンサが、あるかないかだけのシンプルな違いだけになります。

GPIOの入出力電圧には、VDDがそのまま使われます。

DC/DCとLDOを組み合わせて、コア電圧は無線回路などが使う1.3V、プロセッサが使う0.9Vの2種類が作られます。これらはチップ内部でのみ使われます。

システムの動作状態で、DC/DCおよびLDOの動作状態が自動的に切り替わります。

リフレッシュモードの消費電流波形をみると、例えばスライドの例では、350マイクロ秒ごとに、15mA 10マイクロ秒のスパイク状の電流が流れています。

消費電流を計測するときに、普通のテスターをDC電流モードで直接使うと、このようなスパイク状の電流をサンプリングできずに、正しく計測できません。デジタル・マルチメーターの中には、電流値を積分して平均値を表示するもの、例えばADCMTの76461Aなど、がありますが、サンプリング周波数は20kサンプル/秒、5マイクロ秒周期で、10マイクロ秒のパルス電流を測るには、足りません。

nRF52の開発ボードのHardware Filesにある回路図 PCA10036_Schematic_And_PCB.pdf の6シート目を見ると、電流測定用に、P22があり、SB9をパターンカット、R6に適当な抵抗をつければ電流測定に使えるようになっています。

オシロを使うなり、適当な抵抗と大きめの電解コンデンサを組み合わせて、十分なまった波形にするなりして、測定するようにします。

HFCLK

nRF52の32kHzのクロックと32MHzのクロックがあります。HFCLKは32MHzのクロックのことを指します。このクロックはnRF52内部のPLLが出力しています。

外部の32MHzの水晶は、常に発振しているとは限りません。ソフトウェアあるいは内部ハードウェアから、XO REQUESTという信号がHIGHになった時に、水晶発振回路が動作を開始して、それにPLLがロックします。

XO REQUESTがLOWであれば、PLLはフリーラン状態です。またXO REQUESTがたってからPLLがロックするするまで、いくらか時間がかかります。

ADC

8/10/12-bitの逐次比較型ADC(Successive approximation ADC)です。0からVDDまでのフルスケール入力レンジ、シングルエンドまたは差分入力、最大8チャンネル、外部タイマーを必要とせず連続サンプリング(~200kHz)できます。

ADCに限らずnRF52の周辺回路は、通常であれば別にタイマーが必要になる場面でも、そもそもタイマーが必要になる周辺回路には、外部からタイマーを必要としないようになっています。タイマーは貴重な資源ですから、周辺回路に取られずにすむのは、ありがたいです。

nRF51のADCとは、ハードウェアが違うADCが採用されています。ファームウェアからの使い方も、まったく異なります。nRF51からnRF52にコードを移植するときは、ADCを使っているならば、書き直します。

4回サンプルして平均を求めるオーバサンプリングなど、音声用途などに使える機能があります。

PDM, I2S, PWM

PDMは、Two wire digital audio interfaceの略です。マイクロホンに使われる、パルス幅信号入力です。L/Rの2つのマイクロホンから信号を取り込むことができます。

I2Sは、SPIをベースにオーディオ向けに変更されたシリアル・バスインタフェースです。コーデックを内蔵したオーディオ用半導体によく使われています。それらの半導体の接続に使えます。

nRF52のPWMは任意波形の生成にも使えるほど、強力です。おもちゃ品質の音出力であれば、PWMつまりnRF52単体でも、波形を生成、出力できます。またLEDのフェードイン/フェードアウトなどにも使えます。

NFC

nRF52には、NFC-A Listen mode compliant な機能があります。NFC-Aは、13.56MHzの磁界を発生するイニシエータと、その磁界を受け取り負荷変動でイニシエータに信号を返すタグの2つがあります。nRF52がなれるのはタグで、Read/Write Modeをサポートします。nRF52はイニシエータには、なれません。

BluetoothはNFCを、無線通信を使わない鍵交換手段として活用します。無線以外の媒体で鍵を交換することで、セキュリティをより強固にできます。また、NFCはモノ自体に近づかないと反応しないので、いま接続したいものが何かが物理的にわかりやすくなることも利点です。

NFCで鍵を交換する場合、Just works、OOB(Out-of-Band)ペアリング ができます。

nRF52のNFCは3つのモードがあります:

  • DISABLE – すべてが電源オフ
  • SENSE – システムはオンまたはオフ – 消費電流は100nA程度
  • ACTIVATED – フレームの送受信ができる – 400uA程度

NFC-Aのプリコンパイルされたライブラリで、Type 2 Tagの次の機能が使えます。

  • NFC NDEFメッセージフォーマット
  • コネクション・ハンドオーバ・レコード
  • アプリケーション・ランチ・レコード
  • URIレコード

これらを使うと、BLE機器が対応しているアプリケーションを開く、(商品や解説などの)ウェブページを開く、などもできます。

このライブラリがサポートしているのはreadモードだけです。writeモードはメモリ消費量などを考慮して、今は対応されていません。対応はできるので、要望があればwriteも提供するとのことです。

nRF52のファームウェア・開発

Bluetoothの認証を確保したまま、ユーザアプリケーションを動作させるために、半導体と一緒にソフトウェア・デバイスという、スタックや時間制御を行うものをバイナリで提供しています。

ユーザアプリケーションは、タイミング制御などをこのライブラリに任せることで、Bluetoothの認証制度の恩恵を受けることができます。

nRF51ではS110, S120が提供されてきました。これらはメンテナンスモードに。新機能などはS130に移行。S130はnRF52のSDKとAPIが近い。もしもnRF51からnRF52に移行するならば、S130を使っておけば、移行しやすくなるかも。

nRF52のソフトウェア・デバイスは、S132。リリースは2016年2月予定。

  • S132 – タイムスロットAPI。マルチプロトコル。 – メモリの効率、セキュアDFU。 – セントラルとペリフェラルの数、選択設定できる。 – バンド幅、それぞれのリンクごと。設定。

タイムスロットAPIとは、無線回路がBLEに使われていな空き時間に、ファームウェアから利用するAPI。例えば、独自のメッシュネットワークや、独自の無線通信プロトコルを、BLEと共存させながら、ファームウェアで実装できる。

S132はANTを含む。リアルタイムOS、RTXとFreeRTOSに対応している。ソフトウェア・デバイスの上に、リアルタイムOSが乗る形。

  • S132の次 – IPv6 over BLE – L2CAP チャンネル – Long MTUサイズ – 1パケットの255バイトまで

SDKには、標準的なSDKに加えて、他に:

  • IoT SDK
  • HomeKit SDK

がある。

IoT系の話題

省略。メッシュネットワークはどうなる?の質問が多かった。

日本の会社からの無線モジュールのリリース予定

2016年2月あたりから日本の各社から無線モジュール。

質疑応答のまとめ

  • iBeacon用にはnRF51よりもnRF52がおすすめなのか? – nRF52はDCDCまわりが変更されている。自動的にダイナミックにモードを切り替えるから、DCDCを有効にして使え。
  • 電源の入力電圧範囲が最大3.7V。最近のLi-ionでは、3.8Vとかそれ以上になる。Li-po等は想定外か。 – nRF52とは別にDCDCを用意して対応すればよい。(注釈:充電管理ICをつけることになるので、大抵そうなる)
  • Q: nRF52内部のフラッシュには、どのタイミングで書き込まれるのか。 – pstorageというライブラリを通じて行うことで、ソフトウェアデバイスを通じて、フラッシュ書き込みがされる。
  • Q: フラッシュの書き込み位置の分散しているのか – それはしてない。 – (注:)
  • S130とS132の互換性は? – スタックの内部とかは異なってくる。その辺りは違う。まぁいけるか。 – APIは互換。 – 移植、ピン配置まわり、PWMの設定。
  • BLEのセントラル、ペリフェラル、ANT、3つを統合したスタックは出るのか? – nRF51では現在のスタックで、メンテナンス。つまり、でない。 – nRF52で提供。
  • nRF52に対して、ShockwaveやGazelは提供がある? – 提供される。
  • ソフトウェアデバイスにとられる最大の処理時間はどの程度か。 – 60us、最大で。
  • QDID、いままでS110/S130でIDが違う。今後は1つに統合されて? – 統合される。
  • RTOS2つあるけど、どっちがおすすめ? – どっちでも。自分はFreeRTOSが好み。
  • IoT SDK タイムライン? – アルファステート。nRF52のみ。別途マーケティングから。
  • NFC的な、技適みたいななにか制度が必要? – NFCフォラームのロゴ認証程度?
  • サービスとキャラクタリスティクス、数の上限はあるのか? – メモリとチップでの制限。
  • nRF51、キャラクタリスティクス8つくらいだと、繋がりにくかった時が。 – 通信相手の問題じゃない?

Nordicの開発環境で、J-Linke/Liteでリアルタイムなログ取りをする

Nordic Semiconductor社のnRF51822は、BLEシングルモードのSoCとして数多くのモジュールに採用されていて、開発でもよく使います。

SoCのなかにあるCortex-M0はMDK-ARMを使うと、J-Link liteでブレークポイントを4つまで設定できます。通常の組み込み機器のファームウェア開発であれば、デバッグしたければブレークポイントを設定して値や実行フローを確認します。しかしBLEのファーム開発では、止めてしまうと通信が止まってしまいます。

Nordicの開発環境には、SDKにある debug.h をみると、シリアル端子からのprintfデバッグと、フラッシュメモリにログメッセージを貯めておく2つの方法が提供されています。シリアル端子はよく使うのですが、製品化の基板ではIO端子を使いきってしまっていたり、基板に余裕がなくて端子をつけられないなどで、デバッグ専用のシリアル端子が確保できないこともあります。

そのようなときに、SWD (Serial Wire Debug) http://www.arm.com/ja/products/serial-wire-debug.php 経由で、ターミナルにテキスト出力する機能が、SEGGERの Real Time Terminal (RTT) https://www.segger.com/jlink-real-time-terminal.html です。

チュートリアルとソースコードを公開されています。

https://devzone.nordicsemi.com/tutorials/6/debugging-with-real-time-terminal/

printfを、このターミナルにリダイレクトすることもできますが、簡単にsprintfで内部的に切り替えてしまうのもいいのかもしれません。

1
2
3
4
5
6
#define RTT_PRINTF(...) \
do { \
     char str[64];\
     sprintf(str, __VA_ARGS__);\
     SEGGER_RTT_WriteString(0, str);\
 } while(0)
1
#define printf RTT_PRINTF

IoT雑感

IoTとか単語が盛り上がっているので、そういうニュースを見ると影響を受けて、自分が考えていることが変化していくと思う。なので、2015年3月3日の時点で、自分が何を考えていたかのメモ。

IoTって自分がしばしば目にするけど、なぜ話題になるのだろう? わからん。

世の中が動くときは、必ずお金の動きがそこにあるはず。なので、例えばものからデータを取り出すことができるようになったことが世の中を変えるとすれば、その流れは、データを取り出す、そこから意味を取り出す、行動に反映されるの1ループ。

つぎに、どんなものの何のデータ(質や種類)か、意味を取り出すのは誰か(データを生み出した人の端末、データを取得したネットワーク側、データを購入した何者か)、行動に反映する(購買の推薦、道順の提案、割引クーポンを提示する)。3つの段階それぞれに、主語と目的語と動詞、を当てはめて生み出される無数の組み合わせ、それらすべてがIoTと呼べる何かだろうし、その中の幾つかは、強烈なお金の流れを伴ってきそうな気は、なんとなくするといえばしそう。

  1. ニュースの話題が少なくて、取り上げやすいIoTという単語で特集を組むところが多い。

タイトルをみて買う買わない読む読まないを判断する人が多いならば、盛り上がっているならば、タイトルにIoTという単語を入れておきたい。 技術系の話題であれば、ネットワークに接続するものであれば、およそあらゆる話題をIoTという単語に結びつけて話ができる。なので、結びつけてしまえばいい。いろいろな媒体がそれをすると、自然と同期して、全体でなんとなく盛り上がり感がでて、さらにその流れが強まるフィードバックがかかる。

  1. モバイルのニュースに意味がなくなった。

iOSも登場して、新しいサービスやアプリケーションへの関心は、もうない。iPhoneそれ自体、新機種がでても薄い板の別種がでたのか程度でしかない。性能が向上して、初めて手にする人が多い時期は、どんなアプリケーションを使おうかと興味関心が高い。その時期であれば、新しいアプリを紹介して、その広告やインストール実績でお金を得ることもできた。だが、スマフォが日常になれば、いちいちゲームを探すのは、もともとゲームが好きな極めて一部だけに戻る。たいていは、リアルの人脈で、口コミでという流れに、戻るだろう。

  1. 前提が変化した。

スマートフォンが普及したので、データ収集するネットワークに常につながった、いわゆるエッジのデバイスが大量に世にあふれた。また、スマートフォンにアプリケーションを簡単に配布できるので、その普及した装置をインフラとしてとらえて、サービス展開もできるようになった。またAzureなどで機械学習がサービス化されて、データの蓄積とあわせて手軽に運用できるようになっている。

どこかのだれかしかできない特殊な技術だったり、技術自体は公開されても高度すぎて理解できなかったり、あるいは実行環境が高価すぎて、その環境を使いこなせる人の数が少なすぎて、誰か雇って業務として割り当てようにも人がいないとかだと、絵に描いた餅に終わる。また、競合他社も同じ状況だろうから、ちょっと試して効果を見たい程度のモチベーションだろう。そうすると、高価で希少ななにか、に投資する気にはならない。

BLE系を見ていても、センサーやスマートフォンという環境が整い、開発者も何万人単位でいる。いままで絵に描いた餅だった前提が、一気に崩れてる気がするので、もしも競合他社がひっそりそれを試して知見を蓄積していたら?と思えば、手を付けない理由が消えていく気がする。

  1. サービスだとネットワーク側にデータを蓄積することが価値にもなりそう

機械学習やら実行していくとなると、今後の変化にあわせて追従していくなら、フィルタしない生のデータを蓄積しておきたくなる。適当なクラウドサービスを使うとしても、バイト数でみて現実的に引っ越し可能な量を簡単に超える。だから、クラウドサービスを提供する側から見れば、適切な価格で他社にもある機能を同程度に提供しているなら、顧客は簡単には契約先を変えないだろうと思いそう。

サービス提供側も、十分なデータ量をもっているかが、サービスの提供の振る舞いにつながるだろうから、データは貯めるだろうし。

  1. 人間の習慣の変化。

スマフォの経路案内を見て移動するのが日常になってきているから、画面を見て行動するのが、習慣化していそう。また購買活動も画面を見て、気に入ったらその場で発注とか。

  1. IoTというけど先行事例はウェブ系、ただ参考にはならないか

データ収集がはじめから仕組みとして入っていて、ネットワークに接続していて、人の行動を変化させることで利益を得るなら、ウェブ系のあらゆるサービスはそれになる。開発投資も何年もされているから、IoTといえど仕組みはそこにありそう。ただ、成績評価の指数が、人間が何かを買う、人間がリンクをクリックする、人間が画面を見る、なので、その指標がIoTで同じように使えるか?は気をつけないと、仕組みが違うものを無理やりウェブの仕組みで理解したら、勘違いしかなさそう。

  1. 端末機器メーカ

IoTといって、スマートウォッチ(自称)を発表する端末機器メーカがたくさん出てきています。端末機器メーカは、より多くのハードウェアを販売すること、が本能です。そのために、外観デザインやスペックの高さ、あるいは価格の値ごろさをアピールします。

スマートウォッチ(自称)は、Androidなどが提供する通知の仕組みなどに対応することで、Androidのアプリ開発者が用途を開発して利用場面を提供してくれそうですから、ハードウェアだけで閉じこもれるので、手をつけやすそうです。また、端末機器メーカは売上の絶対値もですが、シェアが勝負です。競合他社が持っている商品ジャンルが自社にはないのは、売る本能からすれば恐怖になりそうです。

スマートフォンも、最初の1台が売れる黎明期、年々性能が高まり、その性能に合わせてより魅力的なゲームやアプリケーションが登場する成長期を超えて、いまではたいていの端末でたいていのアプリケーションは快適に動く、必要だから買うだけの成熟あるいは飽和期です。人とは違うものや、必要を超えたハイスペックなど、趣味性の高いものも出せば売れるでしょうが、それはパソコンの時代でも同じように、主流ではありません。

コモディティ化したパソコンの世界では、製造会社は残りませんでした。Dell、あるいはThinkPadを買収したLenovoのように、製造と販売とサポートを統合した会社が、たまたま製造をしていると見るくらいが良さそうです。

  1. 半導体関連

次の半導体のシェアを競う場面として、車載、そしてIoT系も話題としてはありそうです。

車載のキーワードを上げると、安全、事故回避、自動運転系があります。イメージセンサや高周波レーダーのセンサーデバイスからの情報を統合、事前に学習しているデータから危険性があると判断すれば、運転操作に干渉して危険度を引き下げる仕組みです。今の技術や半導体の製造費用が、実用範囲に入り話題になっているのだと思います。技術開発競争は進むでしょうから、基本、人間よりも信頼度は高くなるでしょう。

自動車の動力源が、電気であろうがガソリンであろうが、高度な電子回路が不可欠になります。電気であればモータの制御、ガソリンであっても高い燃費の実現には機械制御が不可欠です。それらの動力源、またブレーキを含めた操作など運転操作の基本機能を支えるために、半導体が不可欠です。その一方で、前に上げた安全装置あるいはカーナビやカーオーディオに人間の目に入るメータ表示など、より多くの台数を売るために、アプリケーションの魅力を高める必要も出てきます。

この組み方は、携帯電話の半導体は、アプリケーション・プロセッサと、通信を制御するベースバンド・プロセッサに分かれて開発されてきた歴史によく似ています。今までの携帯電話での半導体会社の競争と同じパターンを、なぞりそうです。

IoT系は、開発ツールなどを各社で足並みをそろえつつ、独自色を追加して行く感じでしょうか。マイクロプロセッサを販売するためには、開発環境、コンパイラ、そしてそれらに慣れた大量の技術者が必要です。独自のプロセッサコアでは、最後の大量の技術者が確保しづらいでしょうから、今のようにARMに集中する、ライセンス料が高くて払えない場面はMIPSも登場する感じでしょうか。

mbedというハードウェアを抽象化したオンライン開発環境に、各社のクラウドとすぐに連携する評価キットまで登場して、なにか動くものを作るならばスキルも理解すら必要がなく、手順にしたがいサンプルを動かして、ちょっと変更するだけで要望を満たせるまでになってきています。

どうやって半導体会社は儲ける気なのでしょうか。

ウェブ系の開発が参考になるかもしれません。パソコンさえあれば、基本ウェブサービスは開発できます。テキストエディタを開いて、JavaScriptを書いて、ブラウザで動かせばいいでしょう。Node.jsなどもありますから、サーバサイドをローカルで閉じて開発し切ることもできます。開発したものは、AWSなどに乗せてサービスとしてデプロイできます。サービスを開始するまでのコストは金額的にはゼロに限りなく近いです。

ウェブの世界で、開発キットで儲けているところはあるでしょうか。ありません。ウェブ系での儲けは、サービスを提供する側の売上、そしてサービスを提供するインフラを提供する会社の使用料を回収です。半導体自体はサービスが売れれば自動的に売れます。ネットと連携している土俵が同じなら、自社製品も他社製品も価格は同じで、IOやADCなどの周辺、あるいは静電気に強いとか、電源電圧範囲や消費電力、あるいはロジックブロックやアナログブロックを内蔵しているなど、マイコンとしての価値自体でうる、純粋に半導体での商売になりそうです。

  1. ハッカソン

そうはいっても、会社を作って事業となると、雇いたい人は、取りあえず動くものを一人完結で作れる人になりそうです。それは、人数が小さいほうが、やりとりの手間と時間を省けるので早い場合がある。トライ・アンド・エラーをするときには、一人もしくは数人程度の小さいほうが、変なトラブルを巻き込まず純粋に技術だけで動きやすい。など。

そんな人材は教育でどうなるものではなく、たいていは天然物なので、そういう人が反応しそうな面白そうなイベントを開催して、まずリアルな場面に寄せ付ける。そのうえで、フィルタリングをかけて、誰がどの程度できるのかをあぶりだして、雇用を持ちかけるとかに、ハッカソンは便利に使えそうです。

iOS8のvisit Monitorin (訪問先追跡)

iOS8のvisit monitoring

iOSは、位置情報取得が初めて登場した時から、電池消費量に注意して設計されています。位置情報を調べる物理手段は、携帯電話基地局、WiFiルータの識別子、GPS などがありますが、アプリケーションが位置情報を取得するときに、どの物理手段を使うかを直接していすることはありません。必要とする位置精度にあわせて、iOSが最適な物理手段を選択して、アプリケーションに位置情報を通知してくれる作りになっています。

毎年新しい位置情報の技術と機能が導入されているiOSですが、iOS8では、visit monitoring という訪問先の自動記録機能が導入されました。これは24時間365日、ユーザが訪問した場所とその滞在時間を記録し続ける機能です。

Githubのサンプルアプリ。visit monitoringで取得したデータをテキストで表示し続けるだけのサンプルアプリです。

https://github.com/reinforce-lab/ObjC_Codes/tree/master/visitMonitoringTest

visit monitoringの使い方はとても簡単です。

iOS8は、位置情報取得の権限が、when in use, アプリが実行されている間のみ(画面表示されている間のみ)と、always, バックグラウンドなど常に取得、の2つにわかれました。

まず、訪問先を記録し続けるなら、アプリケーションが画面に表示されていない時(バックグラウンド)でも情報が取得できなければ意味がないので、常に情報取得する権限を要求します。

CLLocationManagerのオブジェクトにデリゲートを設定して、 requestAlwaysAuthorization メソッドを呼び出し常に位置情報を取得する権限を要求します。初回呼び出し時には、iOSがユーザに権限要求のダイアログを表示してくれます。

Xcodeで、プロジェクトの Capabilities の Background Modes で Location updates にチェックを入れておくのも、忘れないようにします。

CLLocationManager *_locationManager;
...
_locationManager = [[CLLocationManager alloc] init];
_locationManager.delegate = self;

// requesting a permission. NSLocationAlwaysUsageDescription key must be in your app’s Info.plist file.
[_locationManager requestAlwaysAuthorization];

アプリケーションが実行されると、必ず CLLocationManager のステータス変更が通知されます。権限があれば、位置情報取得を開始したいので、この didChangeAuthorizationStatus: のなかで startMonitoringVisits

-(void)locationManager:(CLLocationManager *)manager didChangeAuthorizationStatus:(CLAuthorizationStatus)status {
    switch (status) {
        case kCLAuthorizationStatusAuthorizedAlways:
            [_locationManager startMonitoringVisits];
            break;
        // 権限がない場合は、なにもしない
        case kCLAuthorizationStatusAuthorizedWhenInUse:            
        default:
        break;
    }
}

- (void)locationManager:(CLLocationManager *)manager didVisit:(CLVisit *)visit {
    //ログを残す
    [self write:[NSString stringWithFormat:@"%@", visit]];
}

visit monitoringは、イベントが発生するたびに iOSは CLVisitのオブジェクトを渡して デリゲートの didVisit: を呼び出します。訪問場所に入った時点、訪問場所を去った時点それぞれ通知が来ます。

どの条件で訪問したと判定するかはわかりませんが、飲食店や書店あるいはオフィスなど、訪問したことに意味がありそうな場所が通知されている感じはしました。電力消費量は、気になるレベルではない感じです。

位置情報の取得にどんな手段を使っているかは、わかりません。CLVisitの位置精度を見ていると、+-60メートル程度のログをよく見るので、おそらく基地局レベルとWiFiを組み合わせて受動的に取れる範囲の位置情報を使っているのではと思います。もしもGPSを利用しているなら+-20メートル以下になるでしょうから。

いまのiOSデバイスは、少ない電力で動きを常時検出できるように、小さいマイコン(M7/M8プロセッサ)が入っています。それらの動き情報も統合して利用しているのだろうとは思います。

電池消費量を気にするにしても、訪問したと判定した瞬間、その瞬間にGPSをONにしてもよさそうなものだと思いますが、訪問先が屋内であったりすること、必要なものは位置精度というより、お店に立ち寄ったといったイベント情報であれば、GPSという精密な位置情報それ自体に意味を見出さない考え方なのかもしれません。

iOSは、WiFiの識別子を取得する関数がプライベートAPIになっていて、ストア承認されたアプリでの利用が禁止されています。ですがiOS自体は、お店のWiFiだとわかるようなデータベースを持っていたりするのかもしれません(あてずっぽう)。屋内地図のデータ提出受付をしたときには、WiFiやiBeaconを含めて、より詳細な位置情報をAppleつまりiOSが持つことになるのは、確実だと思います。

ただ立ち止まったりしただけでも記録されるかなど、実験してみてもいいのかもしれませんが、めんどいのでパス。

何に使うのか

まず思い浮かべるのは、カレログ、ですが、iBeaconの時にそうであったように、単一のアプリの視点からみても、利用場面は出せないものなのだろうと思います。

Bluetooth Low Energy の時もそうでしたが、Appleは、自社が組み上げるサービスに必要な新しい技術要素を、サービス発表の2年前から出してくる感じがします。おそらく、iBeacon、visit monitoringなどは、iOS8以降の世界を組み上げるのに必要な1技術要素なのだろうと思って、とらえたほうが良さそうです。

SceneKitで遊んでみる

SceneKitで遊んでみる

iOS8にはいった、3Dの何かを簡単に作れるSceneKitで遊んでみた。

キャラクタが画面中央に表示されて、5秒に1回ジャンプのアニメを実行する。BananasAsimpleSceneKitplatforminggame と https://github.com/shu223/iOS8-Sampler のSceneKitのサンプルをコピペでつなぎあわせたようなもの。

感じ的には、three.js で3Dしている方の説明とおんなじ感じだなと思った。せっかくだから、ミクさんのアプリを作ればいいのに、3Dデータ変換方法がわからなくて、断念。

Githubのサンプルアプリ。 https://github.com/reinforce-lab/ObjC_Codes/tree/master/SceneKitDaeExample

https://developer.apple.com/library/mac/documentation/3DDrawing/Conceptual/SceneKit_PG/Introduction/Introduction.html

SceneKit Framework Reference https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SceneKit_Framework/

3Dデータの変換

https://github.com/ark-project/ark-project にオープンなデータがあったので、サンプルに使わせてもらった。 cheetah3dというMacのアプリで読み込んで、dae形式に書き出して、テクスチャの設定をする感じ。

モデルが最初真っ白だったから、まず左のペインのMマークのマテリアルで、diffuseにテクスチャの画像ファイルを指定。光の放出を意味するEmissionが白だと、やっぱり白いままなので、これを黒に変更、とかすると3Dモデル+テクスチャが表示される。

lapisの3Dモデルは、上腕部がXcodeでプレビュ表示されない。またビルド時にdae形式のアイルを変換するっぽくて、その時にエラーが出てた。なので、モデルファイルはプロジェクトからは削除してある。

ツールによって、ファイルフォーマットの相性とか、データの作り方や命名方法など、実際にやっていくと、いろいろあるんかもね。

SceneKitの使いどころ

3Dのモデルを読み込み、それを表示させたり、アニメーションをさせたり、物理シミュレーションで動かしたりするのが簡単にできるのが、SceneKit。昨年iOS7で導入された2Dテームを手軽に作れる SpriteKit の3D版といった感じ。

3Dゲームを作る環境には、Unity等がある。それに比べて何か利点があるかというと、多分ない。開発環境を見ても、3Dのモデルはプレビューはできるけど編集能力はないし、物理シミュレーションやアニメーションができるけど、現在のところはインタラクティブに確認する機能もないから、ビルドして振る舞いを見るしかない。プラットフォームもiOSかMacOS縛りになる。

Unityを使うほどではないとか、Unityのラインセスをとって学ぶのが大変だとか、Unityを使った人がいないときに、アプリにちょっと3Dを入れたい場合には便利だと思う。3Dのシーンを見せるのに、レンダリングした動画を入れちゃうと、見るだけになるけど、例えばカメラアングルをぐりぐり動かしたいとか、アプリ側から演出したいとか、そういうときに3Dモデル+アプリ的ななにか、をちょっと入れる場面も、使えると思う。

イメージ的には、アイカツ!ミュージックビデオメーカーみたいな。http://app.famitsu.com/20140806_420069/

あるいは、月齢表示とかのアプリなら、月の3Dモデルに太陽と地球の放射光があたっているさまを、表示するとか。

SceneKitのなかみ

プロジェクトのサンプルコードを見たら、そのままだけど。

表示は、UIViewを継承する SCNView 。これのsceneプロパティに、SCNScene のオブジェクトを入れる。ゲームだと、3D画面の上に操作用画面をいれるけど、それはSCNScene のoverlayなんとかに、SpriteKitの画面を入れられるので、それを使うといいっぽい。

SCNScene は、3Dモデルやアニメーションといったデータを保持するクラス。内部のデータ構造は、SCNNode をノードにする木構造。ノードを作っては、そこにカメラとかオブジェクトとかを張り付けていく。木構造の根は、SCNScene の rootNode プロパティ。

3Dモデルのテクスチャには、リソースの画像ファイルや、文字列やら、CALayerやSpriteKitの画面が貼り付けられる。だから、カメラのプレビュ画面がCALayerから派生しているけど、そういうカメラ動画を貼り付けるとか、そんなのも簡単にできる。

OpenGLのレンダラを生で叩くとか、低レベルなところもありっぽい。OpenGLで別で自分で書いたのと融合とか、面白い事が出来る人には、使いこなせるんあろうと思う。

面白いのは、アニメーションの指定がCoreAnimation。ノードに貼り付けた3Dオブジェクトやライトやカメラの、位置や速度や質量や加速度やらをCoreAnimationでアニメできる。また、アニメのデータは dae 形式のファイルに入れたアニメのデータをCoreAnimationとして読みだすことができるので、別にコードで書かなくてもいい。

2次元のUIのアニメだと思っていたCoreAnimationのスキルが、3Dなところでもそのまま使えるのは、汎用的で面白い。

あとはパッと見たところで:

SCNProgram

OpenGL Shading Language (GLSL)で記述したシーエだープログラムを使ってカスタムなレンダリングを実行する。 バーテックスシェーダー、フラグメントシェーダー

https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SCNProgram_Class/index.html#//apple_ref/occ/cl/SCNProgram

SCRenderer

https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SCNRenderer_Class/index.html#//apple_ref/occ/cl/SCNRenderer

すでにレンダラのコンテキストが指定されているアプリに、別のコンテキストを指定できる。EAGLContext object 。

SCNView。カメラグリグリ動かせる、フレームレート(最大60、デフォルト60)、スナップショット。

https://developer.apple.com/library/ios/documentation/SceneKit/Reference/SCNView_Class/

SCNScene。Vihicleのサンプル、オーバーレイが継承している。

SKSpriteNode。2次元の画像。

SpriteKit(2次元ゲームを作るやる)のシーンをオーバレイ。速度メータとか。

SKScene *scene = self.overlaySKScene
//self はSCNView

SCAAnimationEvent。足音とか、アニメに同期した音

MacとiOSで同じ名前空間

SceneKitとSpriteKitは、MacとiOSで同じ3Dなものを同時開発するのに、便利だと思う。iOSとMacで、名前空間が同じでAPIも同じように振る舞うから、画面サイズが違うだけのなにか、として開発できる。

色を扱うとき、MacだとNSColor、iOSだとUIColorだけど、こういう些細な差分は SpriteKit の SKColor を使えば吸収できるようになっている。SKColor は ifdef で、NSColor と UIColor を切り替えているだけのものだけど、標準のSDKで名前の些細な違いを吸収する仕組みが入っているのが、いい感じ。

色以外にも、いろんな違いがあるんだろうけど、そこまで詳しくないからしらない。

PlayGroundで使えるの?

PlayGroundは、Swiftで簡単なコードを作り、その場で実行して結果を確認できるXcode6の新機能。3Dモデルの読み込み結果及び簡単な動作確認やパラメータの調整に使えると便利だろうと思ったけど、2014年10月3日に、Maverickでの、Xcode6.0.1およびXcode6.1beta(2014年9月30日時点)の2つの環境では無理っぽい。

何が無理っぽかったかというと: 2つの環境で、 MyPlayground.playground を実行してみる。これはiOSをターゲットにしたPlayGroundでの、SceneKitのサンプルコード。

アシスタントエディタを表示(View->Assistant Editor->Show Assistant EditorをON)にすると、実行画面が確認できるけど、

2014-10-03 12:37:51.185 MyPlayground[11251:1205362] Error sending deferral props: 0x10000003

こんなエラーが出る。iOS dev forumをみても、同じようなエラーが報告されているけど、対処はわからない。

iOSターゲットがだめなら、Macターゲットならどうだと思って、そんなPlaygroundをつくろうとすると、Xcode6.0.1はMacのPlaygroundにまだ対応していない。仕方ないので、Xcode6.1beta を入れてMacターゲットで実行しても、エラーはでないけど、なんか表示画面が真っ黒のままで表示されない。

よくわかんない。ツールの問題ということにしておきたい。そのうち動くんじゃないかしらと思う。

リソースの管理

3Dのテクスチャやモデルを管理するなら、アセットにしておくと便利。フォルダを適当に作って、そのフォルダ名に”.scnassets”という拡張子っぽい名前をつけて、Xcodeに放り込めば、アセットとして扱ってくれる。

リソースファイルを追加したいときは、そのフォルダにファイルを放り込めば、自動でXcodeに反映される。

モデルとアニメのファイルはフォルダ構成で区別してやればいい。 例えばサンプルプロジェクトは art.scnassets/characters/explorer/run みたいにして、冒険者のキャラクタの走る場面のアニメーションファイルを入れている。

3Dモデルデータ

Xcode6は、Colladaファイル(.dae)という形式で3Dモデルを読み込める。”Import COLLADA 3D objects and build scenes composed by cameras, lights, and meshes. ” だそうだ。

Colladaファイルは、非営利技術コンソーシアムのクロノス・グループが管理していて、”COLLAborative Design Activity” の略。対話型3Dコンピュータ・グラフィックス・アプリケーション間の、交換用のファイル・フォーマットで、その中身はXMLファイル。バージョン? 1.4で物理学(Physics)、摩擦係数とかが追加されているらしい。カメラとかアニメーションデータとかも1つのファイルで扱えるので便利。

ミクミクダンスとかのファイルをdaeに変換して読み込むフローがつくれると、iOSアプリでお手軽ミクさんフローが作れていいなとおもったけど、MMDの形式をdaeに変換する方法がわからないから、断念。

daeファイルを動的に読み込む方法

ゲームとかだと、データファイルを後からダウンロードさせたいときがある。そのとき、daeファイルが読み込めないとエラーになることがある。

Mac OSだとdaeファイル自体を読み込めるが、iOSのSceneKitは、前処理されたdaeファイルしか読み込めない。http://www.the-nerd.be/2014/11/07/dynamically-load-collada-files-in-scenekit-at-runtime/ ここに詳しく書いてあるように、xscassetsの前処理を自分でコマンド実行して、その結果ファイルを使わないといけない。

/Applications/Xcode.app/Contents/Developer/usr/bin/copySceneKitAssets product-1.scnassets/ -o product-1-optimized.scnassets

ここ、結構引っかかるので、めも。

iOS8の高度計(気圧計)

iOS8の高度計(気圧計)

iPhone6 Plus および iPhone6には、気圧計が入っています。

今どき気圧計は高精度で、気圧の値の変化から、1メートル程度の高さの変化が十分にわかります。これがあると、例えば、ユーザが今ビルの何階にいるかがわかるわけです。

サンプルコードはこんな感じ。

1秒に1回の頻度で、気圧値が更新されて通知されてきます。相対高度(relativeAltitude)は、前回の通知から今回の通知までの高度の変化分を通知しています。今の実装は、おそらく、単純に気圧値の差分に定数をかけるとか、そんな感じなのかもしれません。

更新頻度を指定する方法は、今のところないみたい。

ハードウェから見ると、iPhone6の分解 http://www.techinsights.com/teardown.com/apple-iphone-6/ から、センサは Bosch Sensortec BMP280 Barometric Sensor

仕様を見ると、動作範囲(full accuracy) 300 ~ 1100 hPa、平均測定時間 5.5ミリ秒、分解能0.01 hPa (< 10cm)、温度 0.1度、絶対精度(950 ~ 1050 hPa) +- 1hPa、相対精度 +ー0.12 hPa (高さ+ー1m相当)。 (1hPa(ヘクトパスカル) は 100パスカル。)

センサの仕様から、今の振る舞いは、ほぼセンサの値をそのまま利用する単純な実装をしているのかな、と思いました。

Githubのサンプルアプリ。 https://github.com/reinforce-lab/ObjC_Codes/tree/master/barometer

ここの気圧と高度の計算式で、標高ゼロメートル、温度27度(絶対温度で300K)のときに、1mあたりの気圧の変化は、11パスカル。

http://keisan.casio.jp/has10/SpecExec.cgi?path=05000000.%95%A8%97%9D%8C%F6%8E%AE%8FW%2F02100100.%92n%8Aw%2F12000200.%95W%8D%82%82%A9%82%E7%8BC%88%B3%82%F0%8Cv%8EZ%2Fdefault.xml

アプリの値の変化を見ていると、たしかにそれっぽい感じで、とれている。

ソースコード

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
@interface ViewController () {
    CMAltimeter *_altimater;
    bool _isFirstSample;
    double _currentValue;
    double _averageValue;
    double _altitudValue;
}

@property (weak, nonatomic) IBOutlet UILabel *currentValueTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *averageValueTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *variationValueTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *warningTextLabel;
@property (weak, nonatomic) IBOutlet UILabel *altitudeValueTextLabel;

@end


@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];

    // Do any additional setup after loading the view, typically from a nib.
    _isFirstSample = YES;
    
    self.warningTextLabel.hidden = [CMAltimeter isRelativeAltitudeAvailable];
    if([CMAltimeter isRelativeAltitudeAvailable]) {
        _altimater = [[CMAltimeter alloc] init];
        [_altimater startRelativeAltitudeUpdatesToQueue:[NSOperationQueue mainQueue] withHandler:^(CMAltitudeData *data, NSError *error) {
            [self altitudeDataHandlr:data error:error];
        }];
    }
}

-(void)viewWillDisappear:(BOOL)animated {
    [super viewWillDisappear:animated];

    [_altimater stopRelativeAltitudeUpdates];
}

- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
    // Dispose of any resources that can be recreated.
}

-(void)altitudeDataHandlr:(CMAltitudeData *)data error:(NSError *)error {
    if(error != nil) return;
    
    double altitude = [[data relativeAltitude] doubleValue];
    double pressure = [[data pressure] doubleValue];

    _currentValue = pressure;
    _altitudValue = altitude;

    if(_isFirstSample) {
        _averageValue = pressure;
    } else {
        _averageValue = 0.1 * _currentValue + (1 - 0.1) * _averageValue;
    }
    _isFirstSample = NO;
    
    self.currentValueTextLabel.text  = [NSString stringWithFormat:@"%1.5e", _currentValue];
    self.averageValueTextLabel.text  = [NSString stringWithFormat:@"%1.5e", _averageValue];
    self.altitudeValueTextLabel.text = [NSString stringWithFormat:@"%1.3e", _altitudValue];
    
}