20151201_jeffrey - silenceuncrio/diary GitHub Wiki
- 0905 IoT Platform
- 1225 IoT Platform - discuss with jammy
- 1330 ISO 9001 - 2015條文訓練
- 1720 [文章]比較分析五種常見之國際軟體工程標準
0905
繼續 IoT Platform 的計畫
control center 和 control box 間的溝通方式可以參考
RFC 5414 - CAPWAP
先從 Figure 3: CAPWAP Control Protocol Exchange 這張圖來改
節錄 CAPWAP 相關的資訊再來改 6. Proscend IoT Platform Join Operations
改的還蠻順手的
這就是我實做過 protocol 的優勢
先不要讓別人知道我是從 RFC 改的
1135
覺得這一階段不要把事情搞得太複雜
可以簡化就簡化
但保留擴充的彈性
下午 1330 要去上課
ISO 9001：2015條文訓練
參加人員：全體同仁
日期：2015/12/1(二)
時間：13：30 PM
地點：台灣科學工業園區科學工業同業公會202會議室 竹科展業一路２號
聽說要上到 16:30
今天想把大框寫完的說
至少是跟 Box 溝通的細節能夠訂出來
讓負責 Box 的 Jammy 知道有哪些細項要 implement
不然一個早上他問我的問題我都還沒規劃完呢
1225
跟 jammy 互動後發現不能省略 CAPWAP Discovery 這個機制 再改 IoT Platform Message Exchange
寫到這邊就躲不了要定義 Discovery packet format
CAPWAP 也有相對應的章節可以參考
1330
ISO 9001 課程
1720
剛剛才回到公司
ISO 9001 的課程真的很不錯
其中也有規範到產品開發的流程
我找了下規範軟體開發流程的法規有哪些
找到了這篇 比較分析五種常見之國際軟體工程標準
有時間可以看一下
原本跟業務常態性的 IoT weekly meeting 挪到禮拜四早上十點
我還有明天一天可以完成 IoT Platform 的 message exchange
跟其他成員間溝通的方式要先討論出來
其餘的可以在禮拜四會後再來做
明天還要完成一份自我考核
在下班前交給 處長
預計會花掉我一個小時吧
明天午飯後 1300 來做這件事
IoT Platform Message Exchange
============ ============
Box Center
============ ============
[--------------- begin discovery ------------]
Discover Request
------------------------------------>
Discover Response
<------------------------------------
[--------------- end discovery ------------]
Join Request
------------------------------------>
Join Response
<------------------------------------
[-- Join State Complete --]
(-- enter RUN state --)
:
Configure Request
<------------------------------------
Configure Response
------------------------------------>
:
Event Request
------------------------------------>
Event Response
<------------------------------------
:
Join
Join Request
The Join Request message is used by a Box to request service through
the Center.
When an Center receives a Join Request message it responds with
a Join Response message.
If the Center rejects the Join Request, it sends a Join Response message
with a failure indication.
The Join Request is sent by the Box when in the Join State. The Center
does not transmit this message.
The following message elements MUST be included in the Join Request
message.
o Location Data
o Box Board Data
o Box Name
o Sensor Support
for example:
{
"message": "join-request"
"location" : "room-front-door",
"board" : "Ameba",
"name" : "room"
"sensors" : [
"door open sensor",
"light detect sensor",
"motion detector",
"vibration detector",
"sound detector",
"temperature detector",
"CO2 detector",
"BLE SensorTag"
]
}
Join Response
The Join Response message is sent by the Center to indicate to a Box that
it is capable and willing to provide service to the WTP.
The Box, receiving a Join Response message, checks for success or
failure. If the message indicates success, the WTP proceeds to the Run state.
If the WaitJoin Timer expires prior to reception of the Join Response
message.
If an invalid (malformed) Join Response message is received, the Box
SHOULD log an informative message detailing the error. This error
MUST be treated in the same manner as AC non-responsiveness. The
WaitJoin timer will eventually expire.
The Join Response message is sent by the Center when in the Join State.
The Box does not transmit this message.
The following message elements MUST be included in the Join Response
message.
o Result Code
o Center Name
for example:
{
"message": "join-response",
"name" : "room-center",
"result": "ok"
}
Configure
8.4. Configure Request
Configure Request messages are sent by the Center to provision
the Box while in the Run state. This is used to modify the
configuration of the Box while it is operational.
When a Box receives a Configure Request message, it
responds with a Configure Response message, with a Result
Code message element indicating the result of the configure
request.
The Configure Request is sent by the Center when in the Run
state. The Box does not transmit this message.
One or more of the following message elements MAY be included in the
Configure message:
o ...
8.5. Configure Response
The Configure Response message is the acknowledgement
message for the Configure Request message.
The Configure Response message is sent by a Box after
receiving a Configure Request message.
When an Center receives a Configure Response message, the
result code indicates if the Box successfully accepted the
configuration.
The Configuration Update Response message is sent by the WTP when in
the Run state. The AC does not transmit this message.
The following message element MUST be present in the Configuration
Update message.
o Result Code
Event
Box Event Request
The Box Event Request message is used by a Box to send information to
its Center. The Box Event Request message MAY be sent periodically.
When an Center receives a Box Event Request message it will respond with
a Box Event Response message.
The Box Event Request message is sent by the Box when in the Run
state. The Center does not transmit this message.
The Box Event Request message MUST contain one of the message
elements listed below. More than one of each message element
listed MAY be included in the WTP Event Request message.
o Box Sensor CO2 Statistics
o Box Sensor BeaconTag Statistics
Box Event Response
The Box Event Response message acknowledges receipt of the Box Event
Request message.
A Box Event Response message is sent by an Center after receiving a Box
Event Request message.
The Box Event Response message is sent by the Center when in the Run
state. The Box does not transmit this message.
Discovery Operations
CAPWAP Discovery Operations
The Discovery messages are used by a Box to determine which Centers are
available to provide service.
Discovery Request Message
The Discovery Request message is used by the Box to automatically
discover potential Centers available in the network. The Discovery
Request message provides Centers with the primary capabilities of the
Box. A Box must exchange this information to ensure subsequent
exchanges with the Centers are consistent with the Box's functional
characteristics.
Discovery Request messages MUST be sent by a Box in the Discover
state after waiting for a random delay less than
MaxDiscoveryInterval, after a Box first comes up or is
(re)initialized. A Box MUST send no more than the maximum of
MaxDiscoveries Discovery Request messages, waiting for a random delay
less than MaxDiscoveryInterval between each successive message.
This is to prevent an explosion of Box Discovery Request messages.
An example of this occurring is when many Boxes are powered on at the
same time.
If a Discovery Response message is not received after sending the
maximum number of Discovery Request messages, the Box enters the
Sulking state and MUST wait for an interval equal to SilentInterval
before sending further Discovery Request messages.
Upon receiving a Discovery Request message, the Center will respond with
a Discovery Response message sent to the address in the source
address of the received Discovery Request message.
The Discovery Request message is sent by the Box when in the
Discovery state. The Center does not transmit this message.
The following message elements MUST be included in the Discovery
Request message:
o Discovery Type, see Section 4.6.21
o WTP Board Data, see Section 4.6.40
o WTP Descriptor, see Section 4.6.41
Discovery Response Message
The Discovery Response message provides a mechanism for an AC to
advertise its services to requesting Boxes.
When a Box receives a Discovery Response message, it MUST wait for an
interval not less than DiscoveryInterval for receipt of additional
Discovery Response messages. After the DiscoveryInterval elapses,
the WTP enters the join state and selects one of the Centers that
sent a Discovery Response message and send a join request to that
Center.
The Discovery Response message is sent by the Center when in the Idle
state. The Box does not transmit this message.
The following message elements MUST be included in the Discovery
Response Message:
o AC Descriptor, see Section 4.6.1
o AC Name, see Section 4.6.4