Page 73 - ITU KALEIDOSCOPE, ATLANTA 2019

ICT for Health: Networks, standards and innovation

Table 4 – C++ Code snippet of blood pressure monitor First of all, the authors wrote a C/C++ code which
encapsulates the requirements and functionalities of the
//-----------------------------------------
// Title: [IoTivity][Blood Pressure Monitor] Linked Resource proposed additional functional requirement (atomic
Type: Blood Pressure measurements), which had the potential to affect the core
// Description: Defines "oic.r.blood.pressure" and its behaviors specification [17]. There existed two ways to develop: first
//----------------------------------------- was to modify the core code of IoTivity by adding new APIs
... to the IoTivity library [25] with regard to the new functional
OCRepPayload* getBP1Payload(const char* uri) requirement, and second was to build an application which
{ runs on top of the existing core IoTivity code but not adding
OCRepPayload* payload = OCRepPayloadCreate(); new APIs to the IoTivity library. The authors chose the latter
if(!payload) because building a separate application would save much
{ more time.
OIC_LOG(ERROR, TAG, PCF("Failed to allocate
Payload"));
return nullptr; In this sense, the authors developed a proof of concept (PoC)
} of blood pressure monitor reflecting the atomic
size_t dimensions[MAX_REP_ARRAY_DEPTH] = { 0 }; measurements requirements and uploaded to GitHub for peer
review [26]. Table 4 is a C/C++ code snippet which describes
dimensions[0] = 1; the payload transferred from the blood pressure monitor. The
char * rtStr[] = {"oic.r.blood.pressure"}; payload had to comply with not only the schema in Table 3
OCRepPayloadSetStringArray(payload, "rt", (const char but also the atomic measurement requirements that the
**)rtStr, dimensions);
OCRepPayloadSetPropString(payload, "id", authors proposed. Thus, several APIs defined in IoTivity C
"user_example_id"); SDK [27] and IoTivity C++ SDK [28] were used to describe
OCRepPayloadSetPropInt(payload, "systolic", 0); the payload. For example, OCRepPayloadCreate() function
OCRepPayloadSetPropInt(payload, "diastolic", 0); was used to create a new payload and
OCRepPayloadSetPropString(payload, "units", "mmHg"); OCRepPayloadSetPropInt() was used to set an integer
property to that payload. Meanwhile, the way to encapsulate
return payload; the overall payload and send them on the wire required
} certain routines of combining functions and triggering error

OCF client is prohibited. For example, users need to be able messages. Taking advantage of the existing SDK allowed the
to retrieve their blood sugar level and the time of authors to easily duplicate, test and eventually improve the
measurement simultaneously from his or her glucose meter, deliverables in the future.
in order to properly keep track of the daily glucose level
fluctuation. In this sense, the authors named this additional Finally, the authors proposed new healthcare device
feature as "atomic measurement" and defined its common definitions and asked for a pull request by adding lines of
properties, normative behavior, security considerations and device and resource definitions in JSON format to the OCF’s
other requirements. The proposal was also drafted but had to GitHub repository where the OCF manages all device,
be discussed at a different group (Architecture Task Group) resource and enumeration definitions [29]. In the repository,
where the Core Specification [17] is developed. there is a folder where the information of the device
specification in a machine-readable format is stored. This
4.3 Develop open-source code and test cases repository intends to provide the information in a machine-
readable format for CTT, which in turn, ensures the latest
While the authors were developing the specification for new information of OCF devices for certification program. The
healthcare devices and additional functional requirements, pull request was eventually merged as final.
they had to simultaneously develop the open-source
reference implementation of the proposed specification and Concurrently, the authors had to develop test cases while
test cases for the certification and CTT. developing the code. Test cases in the OCF aim to verify if
the written code well complies with the specification. All
In the OCF, developers are free to choose any open-source mandatory requirements of OCF specifications must have
code for reference implementations. Similarly, the authors corresponding test cases which ensure compatibility and
had the freedom to choose from existing open-source interoperability of OCF devices. The test cases should be
projects which implement OCF specifications or could start able to run in all OCF devices regardless of manufacturers
from scratch. As introduced above, IoTivity has been an and platforms. The approach here for authors was also
OCF-sponsored open-source project since the establishment twofold: the test cases for mandatory resources of each
of the OCF. The project was initiated and developed by healthcare device and the test cases for atomic measurement.
architects of Intel and Samsung Electronics, and periodically The authors developed all necessary test cases, and the test
published stable releases. Any developers can download, cases were incorporated into the CTT. The CTT was
fork, commit and contribute to the existing project to file eventually ready for Plugfest, which is an official OCF
bugs and improve the code. The authors thus decided to take interoperability and compatibility certification event for
advantage of the existing architecture and APIs of IoTivity OCF members to test their device against the CTT and the
using C/C++ [25]. OCF devices of other companies.

– 53 –