nRF51からnRF52へのポーティング作業メモ

nRF51からnRF52へのファーム移植

SenStickというBLEデバイスのファームウェア開発をしています https://github.com/ubi-naist/SenStick 。このデバイスは加速度や照度などの複数のセンサデータを取得し蓄積するものです。

初代はnRF51822(RAM 16kB/ROM256kB)を採用しています。次のデバイスでは、nRF52832(RAM 64kB/ROM 256kB)が採用されます。その次のデバイスへのファームウェア移植で盛大につまづいたところをメモしておこうかなと思います。

ハードの変更

移植で対応するものは、nRF51とnRF52とのハードウェアの違い由来と、使用するソフトデバイスおよびソフトウェア開発キットのバージョンの違い由来の、2種類があります。

今回は、nRF51822(rev3) + S110 + SDK10 を、nRF52(rev1) + S132 + SDK12.1 に移植します。機能は同じであり、またnRF51版とnRF52版とは、基本機能は並行して提供していくので、メンテをやりやすくなるようコードは可能な部分は共有する方針です。

nRF51からnRF52へのハード由来の移植ではまったのは:

  • デジタル・アナログ変換が逐次変換型(Successive approximation ADC, SAADC)。
  • P0.9とP0.10はデフォルトでNFCに割り当てられている。 です。

nRF52はnRF51とは異なる種類のSAADCが採用されました。そして、nRF51のDACとnRF52のSAADCとでは、ハードウェア抽象層(Hardware Abstraction Layer, HAL)とドライバのソースコードが異なります。

ですからADC周りは、自分でラッパーを作ってドライバの違いを吸収するか、コード自体を分離するかします。SDK側で、ADCの種類が違っても、ドライバでHALをラップしてnRF51とnRF52どっちでも同じコードで動くようにしといてくれたらいいのにって思いますが。

P0.9とP0.10は、デフォルトでNFCに割当てられています。ですから何も設定をしないと、GPIOとして設定していても、GPIOとして機能しません。この2つのピンを通常のGPIOとして使うには、レジスタ設定が必須です。

出てくるはずの信号が全く出てこないで、はまるとけっこう精神的にきついです。データシートには、その旨が書いてあるのですが、よく読まずに回路を組むと、信号が出てこないと頭を抱えることになるので、やっかいです。

C/C++のプリプロセッサシンボルで、CONFIG_NFCT_PINS_AS_GPIOS を定義しておけば、P0.9とP0.10はGPIOとして使えるようになります。この処理は system_nrf52.c にあって、こんなコードです:

/* Configure NFCT pins as GPIOs if NFCT is not to be used in your code. If CONFIG_NFCT_PINS_AS_GPIOS is not defined,
   two GPIOs (see Product Specification to see which ones) will be reserved for NFC and will not be available as
   normal GPIOs. */
#if defined (CONFIG_NFCT_PINS_AS_GPIOS)
    if ((NRF_UICR->NFCPINS & UICR_NFCPINS_PROTECT_Msk) == (UICR_NFCPINS_PROTECT_NFC << UICR_NFCPINS_PROTECT_Pos)){
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        NRF_UICR->NFCPINS &= ~UICR_NFCPINS_PROTECT_Msk;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        NVIC_SystemReset();
    }
#endif

不揮発の設定レジスタをみて、NFCにピンを割り当てる設定になっていたら、そのフラグをクリアする、というコードです。ほぼおまじないなので、プリプロセッサに CONFIG_NFCT_PINS_AS_GPIOS を定義して忘れましょう。

Swift3でのBLEアプリ開発-その1-

Swift3でBLEアプリを作ってみる

これは Bluetooth Low Energy Advent Calendar 2016 の12月1日の記事です。

Swift3が急速に広がっていますが

Objective-Cに続く新しい言語としてApple社からSwiftが公開されて、はやバージョン3になりました。

Swift3ではApplication Binary Interface (ABI)の大きな変更が入り、そのためSwift2でビルドされたライブラリをSwift3から呼び出せないなど、Swift2とSwift3との混在ができません。この破壊的な変更が強制力になり、ライブラリやアプリケーションのSwift3対応が加速されています。

自分がアプリケーションやライブラリをSwift3で書き直さねばならないときは、どのような言語で書いても同じ振る舞いをするものを言語の都合で書き直す手間が無駄に思えて、恨み言を言いながら作業をします。これって、ほんっと作業なんですよね…

ですが、Swift2からSwift3への移行はかなりスムースにいきます。それはXcodeの変換ツールのおかげだけではありません。アプリ開発は、いろいろなライブラリを取り込んで作りますが、それらのプロジェクトが生きているライブラリが軒並み、Swift3での破壊的な変更のお陰で、一気にSwift3対応を勧めていたおかげです。

自分が作業をするときは恨み言を言いますが、他人の仕事だと、べんりだなーって思うので、いい加減なものです。ですが、ライブラリがSwift3に移行して逆にデフォルトがSwift3となり、アプリをSwift3へ移行する圧力も高まっているんだろうなと思ったりします。

Swift2版はgithubで切られたブランチで参照して取ってこないとないよとか、おもしろいことになるのと、バグ修正があっても、Swift3に移行完了していたら、わざわざSwift2もメンテするかなとか思いますしね。

iOSでBLEを使うアプリは、CoreBluetoothフレームワークを使います。ですからSwift3であっても、これまでのアプリづくりと何ら変わるところはありません。

しかしSwiftならではの話もあるので、ともあれ、Swift3でBLEのライブラリあるいはアプリを作る話でもしてみます。

SenStickのソースコードをもとにして

BLE系の開発コードは、アプリケーションを作ってもらうためのSDKをバイナリ、場合によってはソースコードで公開することはよくあります。ですが、BLEデバイスの製造販売が利益源ですから、そのBLEデバイス側のソースを公開することはありません。

BLEのセンサロガー https://github.com/ubi-naist/SenStick は全てがオープンソースで公開されているので、これをサンプルにします。これのコードは私が書いています。

お仕事のコードはたいてい納品したら相手のものですから、誰かの目に触れることは滅多とないのですが、これは大学のプロジェクトでもあり、またハードウェアはゴミでしかない、という話が通じる人たちなので、公開されたっぽいです。

アプリでBLEデバイスを使うSDK tree/master/SenStickSDK これのコードを見ていきます。

バイト配列と値型の変換

BLEのキャラクタリスティクスを通じてやり取りするのはバイト配列です。キャラクタリスから読み出したバイト配列は、値や構造体に変換しなければなりません。また、キャラクタリスに書き込む場合は、その逆に値や構造体をバイト配列に変換します。

このバイト列と値との変換は、extensionで作っています。 PackableType.swift にまとめています。

なんとなくByte型
public typealias Byte = UInt8

まず、UInt8にByteという別名を与えます。単なる好みで、どうでもいいことだし、UInt8でいいじゃないと思うのですが、このコードを書いていたときの気の迷いです。あとで、UInt8で置換しときます…

public protocol PackableType {
    func pack(byteOrder: ByteOrder) -> [Byte]
    static func unpack(_ data: Array<Byte>, byteOrder: ByteOrder) -> Self?
}

そしてバイト配列と値型それぞれの変換メソッド名を与えます。これはシリアライズ/デシリアライズなのですが、アルファベットにするとserialize/deserializeと文字数が長いです。そのわりに、‘de’の部分しか違わないので、まずありえないのですがなんとなーくタイプミスしそうだな(賢い補完があるからそんなことあるわけないのですが)と、なんとなーくで、pack/unpackという名前にしてみました。

気の迷いです。素直にserialize/deserializeでよかったなって、今書いてて思います。

public enum ByteOrder : CustomStringConvertible {
    case littleEndian
    case bigEndian

    public var description: String {
        switch self {
        case .littleEndian: return "LittleEndian"
        case .bigEndian: return "BigEndian"
        }
    }
}

エンディアンを指定するためにenum型で定義しておきます。デバッグ時に文字列で表示できると便利(かな)と思うので、enum側は必ず文字列に変換できるようにコーディングしています。

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

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