How to Prototype Insecure IoTivity Apps with the Secure Library

IoTivity 1.3.1 has been released, and with it comes some important new changes. First, you can rebuild packages from sources, with or without my hotfixes patches, as explained recently in this blog post. For ARM users (of ARTIK7), the fastest option is to download precompiled packages as .RPM for fedora-24 from my personal repository, or check ongoing works for other OS.

Copy and paste this snippet to install latest IoTivity from my personal repo:

distro="fedora-24-armhfp"
repo="bintray--rzr-${distro}"
url="https://bintray.com/rzr/${distro}/rpm"
rm -fv "/etc/yum.repos.d/$repo.repo"
wget -O- $url | sudo tee /etc/yum.repos.d/$repo.repo
grep $repo /etc/yum.repos.d/$repo.repo

dnf clean expire-cache
dnf repository-packages "$repo" check-update
dnf repository-packages "$repo" list --showduplicates # list all published versions
dnf repository-packages "$repo" upgrade # if previously installed
dnf repository-packages "$repo" install iotivity-test iotivity-devel # remaining ones

I also want to thank JFrog for proposing bintray service to free and open source software developers.

Standalone Apps

In a previous blog post, I explained how to run examples that are shipped with the release candidate. You can also try with other existing examples (rpm -ql iotivity-test), but some don’t work properly. In those cases, try the 1.3-rel branch, and if you’re still having problems please report a bug.

At this point, you should know enough to start making your own standalone app and use the library like any other, so feel free to get inspired or even fork demo code I wrote to test integration on various OS (Tizen, Yocto, Debian, Ubuntu, Fedora etc…).

Let’s clone sources from the repo. Meanwhile, if you’re curious read the description of tutorial projects collection.

sudo dnf install screen psmisc git make
git clone http://git.s-osg.org/iotivity-example
# Flatten all subprojects to "src" folders
make -C iotivity-example
# Explore all subprojects
find iotivity-example/src -iname "README*"

 

 

Note that most of the examples were written for prototyping, and security was not enabled at that time (on 1.2-rel security is not enabled by default except on Tizen).

Serve an Unsecured Resource

Let’s go directly to the clock example which supports security mode, this example implements OCF OneIoT Clock model and demonstrates CoAP Observe verb.

cd iotivity-example
cd src/clock/master/
make
screen
./bin/server -v
log: Server:
Press Ctrl-C to quit....
Usage: server -v
(...)
log: { void IoTServer::setup()
log: { OCStackResult IoTServer::createResource(std::__cxx11::string, std::__cxx11::string, OC::EntityHandler, void*&)
log: { FILE* override_fopen(const char*, const char*)
(...)
log: } FILE* override_fopen(const char*, const char*)
log: Successfully created oic.r.clock resource
log: } OCStackResult IoTServer::createResource(std::__cxx11::string, std::__cxx11::string, OC::EntityHandler, void*&)
log: } void IoTServer::setup()
(...)
log: deadline: Fri Jan  1 00:00:00 2038
oic.r.clock: { 2017-12-19T19:05:02Z, 632224498}
(...)
oic.r.clock: { 2017-12-19T19:05:12Z, 632224488}
(...)

Then, start the observer in a different terminal or device (if using GNU screem type : Ctrl+a c and Ctrl+a a to get switch to server screen):

./bin/observer -v
log: { IoTObserver::IoTObserver()
log: { void IoTObserver::init()
log: } void IoTObserver::init()
log: } IoTObserver::IoTObserver()
log: { void IoTObserver::start()
log: { FILE* override_fopen(const char*, const char*)
(...)
log: { void IoTObserver::onFind(std::shared_ptr)
resourceUri=/example/ClockResUri
resourceEndpoint=coap://192.168.0.100:55236
(...)
log: { static void IoTObserver::onObserve(OC::HeaderOptions, const OC::OCRepresentation&, const int&, const int&)
(...)
oic.r.clock: { 2017-12-19T19:05:12Z, 632224488}
(...)

OK, now it should work and the date should be updated, but keep in mind it’s still *NOT* secured at all, as the resource is using a clear channel (coap:// URI).

To learn about the necessary changes, let’s have look at the commit history of the clock sub project. The server’s side persistent storage needed to be added to the configuration; we can see from trace that Secure Resource Manager (SRM) is loading credentials by overriding fopen functions (those are designed to use hardware security features like ARM’s Secure Element/ Secure key storage). The client or observer also needs a persistent storage update.

git diff clock/1.2-rel src/server.cpp

(...)
 
+static FILE *override_fopen(const char *path, const char *mode)
+{
+    LOG();
+    static const char *CRED_FILE_NAME = "oic_svr_db_anon-clear.dat";
+    char const *const filename
+        = (0 == strcmp(path, OC_SECURITY_DB_DAT_FILE_NAME)) ? CRED_FILE_NAME : path;
+    return fopen(filename, mode);
+}
+
+
 void IoTServer::init()
 {
     LOG();
+    static OCPersistentStorage ps {override_fopen, fread, fwrite, fclose, unlink };
     m_platformConfig = make_shared
                        (ServiceType::InProc, // different service ?
                         ModeType::Server, // other is Client or Both
                         "0.0.0.0", // default ip
                         0, // default random port
                         OC::QualityOfService::LowQos, // qos
+                        &ps // Security credentials
                        );
     OCPlatform::Configure(*m_platformConfig);
 }

This example uses generic credential files for the client and server with maximum privileges, just like unsecured mode (or default 1.2-rel configuration).

cat oic_svr_db_anon-clear.json
{
    "acl": {
       "aclist2": [
            {
                "aceid": 0,
                "subject": { "conntype": "anon-clear" },
                "resources": [{ "wc": "*" }],
                "permission": 31
            }
        ],
        "rowneruuid" : "32323232-3232-3232-3232-323232323232"
    }
}

These files will not be loaded directly because they need to be compiled to the CBOR binary format using IoTivity’s json2cbor (which despite the name does more than converting json files to cbor, it also updates some fields).

Usage is straightforward:

/usr/lib/iotivity/resource/csdk/security/tool/json2cbor oic_svr_db_client.json  oic_svr_db_client.dat

To recap, the minimal steps that are needed are:

  1. Configure the resource’s access control list to use new format introduced in 1.3.
  2. Use clear channel (“anon-clear”) for all resources (wildcards wc:*), this is the reason coap:// was shown in log.
  3. Set verbs (CRUD+N) permissions to maximum according to OCF_Security_Specification_v1.3.0.pdf document.

One very important point: don’t do this in a production environment; you don’t want to be held responsible for neglecting security, but this is perfectly fine for getting started with IoTivity and to prototype with the latest version.

 

Still Unsecured, Then What?

With faulty security configurations you’ll face the OC_STACK_UNAUTHORIZED_REQ error (Response error: 46). I tried to sum up the minimal necessary changes, but keep in mind that you shouldn’t stop here. Next, you need to setup ACLs to match the desired policy as specified by Open Connectivity, check the hints linked on IoTivity’s wiki, or use a provisioning tool, >stay tuned for more posts that cover these topics.

 

 

 

Building IoTivity for ARM on ARTIK Devices

There are several options to build IoTivity for ARM targets or any non x86 hardware, but first you have to decide which operating system you want to use. In this article, I won’t compare OS or devices; instead, I’ll give a couple of hints that apply to ARTIK 5, 7, and 10 devices (not the ARTIK 0 family, which run TizenRT). These steps can also be applied to other single board computers like the Raspberry PI.

Build for Tizen with GBS

The first and easiest way to build IoTivity is for Tizen, using GBS. This process was explained in a previous article.

For your knowledge, GBS was inspired by Debian’s git-build-package and uses an ARM toolchain that runs in a chrooted ARM environment using QEMU. Both ARTIK boards and the Raspberry Pi are used as Tizen reference platforms.

Build for Yocto with Bitbake

The second option is to crossbuild with the Yocto toolchain. Theoretically, it should be the fastest way, but in practice it might be the opposite because external packages will be rebuilt from scratch if the project doesn’t provide a Yocto SDK; this can be a long, resource consuming process.

Anyway, this is what is used in some OSS automotive projects (like AGL or GENIVI); the following slides provide a tutorial to get familiar with bitbake and OE layers (like meta-oic for IoTivity).

This can then be deployed to ARTIK 5 or 10 using meta-artik (ARTIK7 might need extra patches).

Cross Building Manually

Another option is to setup your toolchain with the scons environment, but I would not recommend it because you’ll probably lack tracking or control (output binaries will not be packaged) and risk consistency issues. If you choose this method, refer to IoTivity’s wiki page about crossbuilding.

Build on the Device

The last and most obvious option is to build on the device itself; this takes a bit longer, but is totally possible assuming your device has the resources (it worked for me on the RPI3 and ARTIK10). For this to work cleanly I suggest you build system package if your distro is supports it it (.rpm, .deb etc). This way you can track the different build configurations and avoid mistakes caused by manual operations.

Build on ARTIK10

ARTIK 10 supports building with Fedora 22, RPM packages can be built from Tizen’s spec file plus a handful of patches (I needed to use scons install and avoid duplication of packaging efforts). This work is still under review in the master branch, and will be backported to 1.3-rel branch once 1.3.1 is released. Meanwhile, you can clone my sandbox branch.

mkdir -p ${HOME}/rpmbuild/SOURCES/
git clone http://github.com/tizenteam/iotivity -b sandbox/pcoval/on/next/fedora
cd iotivity
git archive HEAD | gzip - > ${HOME}/rpmbuild/SOURCES/iotivity-1.3.1.tar.gz
rpmbuild -ba tools/tizen/iotivity.spec -D "_smp_mflags -j1" 

This is easy because the ARTIK10 has a lot of eMMC and RAM. The 8-core CPU is nice, but it won’t help because parallelizing too much will eat all of the device’s RAM. To be ensure reproductibility use -j1, but if you’re in a hurry you can try -j2 or more.

Build on ARTIK7

The next challenge is the ARITK710 which less powerful than ARTIK10 (RAM=1GB , eMMC=4GB) and uses Fedora 24. This is a slightly less favorable case because there are some extra steps due to the RAM and disk space being more limited. We’ll use extra storage to add a memory swap and mock: a nice Fedora tool to build RPM from git sources (it’s very similar to pbuilder for Debian). Extra storage can be connected to the board via SD or USB bus, but I prefer to use NFS; it’s not optimal, but it works.

Setup NFS

First, setup NFS on your development host and share a directory on the LAN; mine is Debian based:

sudo apt-get install nfs-kernel-server
mkdir -p /tmp/srv/nfs
ifconfig # Note interface IP to be used later

cat /etc/exports
# TODO: LAN's IP might be adjusted here:
/tmp/srv/nfs 192.0.0.0/255.0.0.0(rw,sync,no_root_squash,no_subtree_check)

Use NFS

Now, login to the target and install NFS and the other tools we’ll use:

dnf remove iotivity # Uninstall previous version if present
dnf install nfs-utils mock-scm mock rpm-build screen

Mount a directory for the device:

mnt=/tmp/mnt/nfs/host/$(hostname)/
host=192.168.0.2 # TODO adjust with IP of your host
mkdir -p $mnt ; mount $host:/tmp/srv/nfs $mnt

Attach a swap file:

file="$mnt/swap.tmp"
dd if=/dev/zero of=$file bs=1k count=2097152 # 2GB

losetup /dev/loop0 "$file"
mkswap /dev/loop0
swapon /dev/loop0

Because the eMMC is also limited, the build will be done in remote storage too. This won’t use an NFS shared folder directly because mock doesn’t support it, so let’s cheat it by mounting an ext4 partition file over NFS, the same way we did above:

file="$mnt/ext4.tmp"
dd if=/dev/zero of=$file bs=1k count=2097152 # 2GB

losetup /dev/loop1 "$file"
mkfs.ext4 /dev/loop1

src=/dev/loop1
dst=/var/lib/mock/
mount $src $dst

Build IoTivity

Create a user to run mock on remote filesystem:

user=abuild # TODO change if needed
adduser $user
home="/home/$user"
mnt=/tmp/mnt/nfs/host/$(hostname)/
mkdir -p "$home" "$mnt$home"
chown -Rv $user $s "$home" "$mnt$home"
mount --bind "$mnt$home" "$home"

su -l $user

Mock is pretty straightforward, but here is an example of the upcoming 1.3.1 release with the patches I mentioned above. If necessary, you can rebase your own private repo on it.

package=iotivity
url="https://github.com/TizenTeam/iotivity.git"
branch="sandbox/pcoval/on/next/fedora"
conf="fedora-24-armhfp"
spec=./tools/tizen/iotivity.spec
  
time mock -r "$conf" \
    --scm-enable \
    --scm-option method=git \
    --scm-option package="${package}" \
    --scm-option git_get=set \
    --scm-option write_tar=True \
    --scm-option branch="${branch}" \
    --scm-option git_get="git clone $url" \
    --scm-option spec="${spec}" \
    --resultdir=${HOME}/mock \
    --define "_smp_mflags -j1" \
    #eol

Now wait and check log trace:

You are attempting to run "mock" which requires administrative
privileges, but more information is needed in order to do so.
Authenticating as "root"
Password: 
INFO: mock.py version 1.3.4 starting (python version = 3.5.3)...
(...)
Start: run
(... time to clone and build iotivity repo ...)
Finish: rpmbuild iotivity-1.3.1-0.src.rpm
Finish: build phase for iotivity-1.3.1-0.src.rpm
INFO: Done(/home/abuild/mock/iotivity-1.3.1-0.src.rpm) Config(fedora-24-armhfp) 116 minutes 1 seconds
INFO: Results and/or logs in: /home/abuild/mock
INFO: Cleaning up build root ('cleanup_on_success=True')
Start: clean chroot
Finish: clean chroot
Finish: run

Depending on network bandwidth, RPMs will be produced in a reasonable time (less than a night for sure).

You can now validate reference examples:

su root -c "dnf remove -y iotivity"
su root -c "dnf install -y --allowerasing ${HOME}/mock/iotivity*.arm*.rpm"

rpm -ql iotivity-test

cd /usr/lib/iotivity/resource/examples ; ./simpleserver 2 
# 2 is needed to enable security node.

In other session:

cd /usr/lib/iotivity/resource/examples ; ./simpleclient
GET request was successful
Resource URI: /a/light
Server format in GET response:10000
Server version in GET response:2048

Bringing it all Together

There has been one major relevant change since 1.2.x, the default build configuration is using secured mode (Tizen had it enabled for longer). For developers, this means that if your application is not configured to support security ACL, it won’t work, and you might expect this OC_STACK_UNAUTHORIZED_REQ error:

onGET Response error: 46

The following presentation provides some insight on the IoTivity security features.

The fall back option is to rebuild IoTivity without SECURITY enabled (using –define SECURED 0), but this won’t be certified as OCF compliant. Finally, these build steps can be replicated for other projects using IoTivity.

How OCF is Creating the Connected Car

The Connected Car & Fragmentation

Traditional car manufacturers have begun including early iterations of touchscreen technology with access to media and apps that can also provide basic HVAC (Heating, Ventilation and A/C) controls for the vehicle. These features can often be accessed through mobile devices with tailor-made apps from each car maker. However, this has led to OEMs building their own ecosystem silos, similar to the trends observed in the smartphone industry. The lack of an open, standardized framework has resulted in a fragmented market, where experiences from one OEM won’t work with another in any streamlined way; consequently, developers aren’t thinking about how to provide a rich user experience that allows cars and drivers to work in unison; this is a huge missed opportunity.

Samsung OSG, OCF, and IoTivity

The Open Connectivity Foundation (OCF) is creating a specification and sponsoring the IoTivity open source project to deliver an open and secure connectivity and interoperability framework; this enables devices from multiple vendors that belong to multiple vertical domains to run on a variety of software and hardware platforms. Automotive is one key vertical where OCF can have a significant impact. The Samsung Open Source Group (OSG) has been playing a significant role in both the Open Connectivity Foundation (OCF) and IoTivity.

Collaboration with Genivi & W3C

The GENIVI Alliance, a community that’s developing open source software and standards for the connected car, and OCF are partnering to co-develop open standards for vehicle connectivity and vehicle data exchange, including a unified model for secure discovery and exchange of information between smart homes, connected cars, and other IoT devices. The joint effort will also address end-to-end security challenges to enable new opportunities across multiple verticals. Additionally, GENIVI and OCF will  closely collaborate with the W3C Automotive Working Group, which develops the Open Web Platform API specification to expose vehicle data to web application developers.

Proof of Concept

Through a broad collaboration spanning ten organizations, we were able to develop and showcase our demo at the OCF booth at CES 2017.  ETRI, Genivi Alliance, Honeywell, Intel, Jaguar Land Rover, OCF, Samsung, Tinnos, The Data Alliance, and W3C all collaborated on open specifications and open source software to realize numerous interesting connected car use cases and explore interoperability between smart home devices and the connected vehicle.

Source Code

If you are interested in recreating these demos, or would like to experiment with it, base of demo code have been shared on the Samsung OSG git repository. To get started with IoTivity on GENIVI, simply add the “meta-ocf-automotive” layer, which includes minimalistic examples that demonstrate IoTivity. You can use the following as a guideline, for Yocto based distros.

# Fist Setup yocto buildenv, then
git clone https://github.com/GENIVI/genivi-dev-platform 
cd genivi-dev-platform 
git clone http://git.s-osg.org/meta-ocf-automotive/ 
MACHINE=qemux86-64 # Or supported BSPs (raspberrypi, minnowboard, dragonboard...)
echo 'BBLAYERS += "${TOPDIR}/../meta-ocf-automotive"'  >> 'gdp-src-build/conf/templates/bblayers.inc' 
source ./init.sh $MACHINE bitbake genivi-dev-platform

Once booted on qemu or the Raspberry Pi 2/3, an IoTivity server can be started from “/opt/iotivity-example*” and example clients can be run on the same LAN, including localhost. These examples are part of our IoTivity example, and are ready to be forked to create your own IoT services. We hope it will inspire you and simplify integration; start learning! For support, check out the detailed instructions on IoTivity’s automotive wiki page. Since GENIVI’s development platform is now shipping iotivity-node, linking sensors to the cloud as shown at FOSDEM, can be done in a jiffy.

Working together across organizational boundaries has enabled us to realize these demonstrations with real devices that run open source software; hopefully this will help people understand the potential business opportunities of connected cars. Feel free to post a comment below if you have any questions or comments.

Additional Resources

[wp_biographia user="pcoval"]

[wp_biographia user="sanjeev"]

Get Started with IoTivity Interactions on the ARTIK10 and Tizen

A curious mind recently asked me to share materials about the OCF SmartHome demo, or perhaps I should call it the “Minimalist Smart Switch” instead. The demo was displayed at the Embedded Linux Conference in Berlin, and featured IoTivity running on an ARTIK10 SoC that connected to a Tizen Gear S2 Smartwatch; both run Tizen OS.

Get Started with IoTivity Interactions on the ARTIK10 and Tizen - ocf

You will find more technical details in the following slide deck.

Install Tizen and IoTivity

If you want to run it this demo, you can download the system image and uncompress the archive directly to the SD card using QEMU tools.

lsblk # will list all your disks
disk=/dev/sdTODO # update with your disk id
file=tizen-common-artik10-20160801rzr.qcow2
sudo qemu-img convert -p "${file}" "${disk}"
sync 

Once this is completed, insert the SD card into the ARTIK10 and turn it on; it will boot Tizen and launch the IoTivity server. For more information about this, check out the previous blog posts about booting tizen on ARTIK and building software for Tizen OS. These will show you how to rebuild the latest version of IoTivity from scratch.

Of course, this can be adapted to other hardware like the ARTIK5 and maybe the ARTIK7 too, it would be a good idea to bookmark this page as a reference for Tizen on ARTIK. If you run into issues, feel free to ask about them in the ARTIK forums.

Note, You can also do it again on Yocto OS using meta-artik too, but using Tizen will save you the time and resources to rebuild everything.

Setup the Tizen Clients

For IoTivity clients on mobile devices, like the Samsung Z1, or smartwatches, such as the Samsung GearS2, the clients need a little preparation. Most of it’s documented in the Tizen page on the IoTivity wiki. I will also be personally available to assist developers at next the Tizen community meeting (2016-11-28 09h@UTC), which has more details on the Wiki’s Meeting page.

What’s Next for Tizen and IoTivity?

Micro-controllers have recently been a focus of some of my work. I shared some hints are shared in the following presentation “From Arduino Microcontrollers to Tizen using IoTivity” which I presented at IoT With the Best 2016.

Others at the Samsung Open Source Group have worked on more constrained devices by bridging different technologies together, including JerryScript, 6LoWPAN, and more. This was demonstrated at the recent Samsung Open Source Conference .

One likely challenge for ARTIK0 owners will be running iotivity-constrained on operating systems Iotivity supports, such as RIOT, Zephyr, and Tizen RT. If you’re one of these people, please keep us updated in the Tizen IRC channel, or the mailing lists!

Get Started with IoTivity Interactions on the ARTIK10 and Tizen - lfelc

Thanks to Luis De Bethencourt for helping me with the pictures of the Gear S2 on my wrist :-)

Open Connectivity Foundation and AllSeen Alliance Merger: a Primer

You probably saw the announcement on October 10, 2016 that the Open Connectivity Foundation and the AllSeen Alliance will merge and create a ‘best of both’ IoT framework.

OCF_4CTo recap briefly, the Board of Directors from both organizations have agreed to consolidate operations under the Open Connectivity Foundation (OCF), while the open source projects will continue to be hosted at the Linux Foundation. I’ve noticed some confusion about what exactly happened, so I thought I would clarify some things in this article.

To start, OCF and the AllSeen Alliance are each non-profit entities that are responsible for the business operations of each project. In addition, OCF hosts development of the specification. Each organization has their own bylaws, membership agreement, IPR policy, and charter. By law they must be governed by a board of directors, which consists of representatives from member organizations.

One of the major differences between the two is that OCF also maintains a specification and a certification program which allows multiple implementations. On the other hand, AllSeen Alliance certifies specific releases of the AllJoyn project.

Open Connectivity Foundation and AllSeen Alliance Merger a Primer - iotivity_logo_hexagon_pantone-1Separately, each has an open source project associated with it. Under OCF, that project is IoTivity. OCF is the sole sponsor of IoTivity, which means that OCF members are also sponsoring IoTivity; its charter is to produce an Apache 2.0-licensed reference implementation of the OCF spec. There is an open source working group in OCF which works with the IoTivity project on this. Likewise, AllJoyn is the project under AllSeen Alliance. In both cases, the funds collected from OCF and AllSeen Alliance’s membership dues help fund the operations of their respective projects, which are hosted at the Linux Foundation.

Following the open source best practice of separating technical governance from non-technical governance, each project has their own hierarchy of decision makers. While the open source projects have representation in OCF and AllSeen Alliance (via a nominated representative), they are separate projects which make their own technical decisions.

Now, getting to the merger. On Monday, it was announced that OCF and AllSeen Alliance will combine at the organizational level. This means that from a business perspective, they will consolidate under the OCF name, IP policy, bylaws, and membership terms. From a business perspective, the two have become one.

On the other hand, AllJoyn and IoTivity are still separate projects at the Linux Foundation. It’s a lot harder to merge two separate codebases than it is two organizations. For the time being, it looks like they will remain separate. This makes good technical sense, as it ensures a stable codebase for security updates to products which are already in the market based upon existing code.

A workgroup within OCF will maintain AllJoyn 16.10for now, but it will be the last version you can certify under the AllSeen Alliance IP policy. Also, as part of the merger, the Apache 2.0 license was added to the existing ISC license on the AllJoyn codebase.

With that said, the stated goal here is convergence. It has been noted elsewhere that many former AllJoyn developers are now working on IoTivity. The goal is to evolve the OCF spec and IoTivity itself to be interoperable and backwards compatible with both. So over time, the expectation is that IoTivity will be the single official reference implementation for the merged effort.

Our hope is that this will lead to a stronger, more stable, diverse community of contributors who will continue to evolve IoTivity into bigger and better things.

How to Boot Tizen on ARTIK

The fact that Tizen can be run on ARTIK is not the latest breaking news, considering it was previously demonstrated live at the 2015 Tizen Conference. There, the ARTIK project was also explained as an IoT platform of choice. Since then, ARTIK has become a new Tizen reference device, so here are a couple of hints that will help you test upcoming Tizen release on this hardware. First let me point out that Tizen’s wiki has a special ARTIK category, where you’ll find ongoing documentation efforts, you’ll want to bookmark this page.

In this article, I will provide a deeper explanation of how to use the bleeding edge version of Tizen:3.0:Common on ARTIK10, and how to start working on this platform. As explained in my previous Yocto/meta-artik article, I suggest you avoid using the eMMC for development purposes; for this article I will boot the ARTIK from an SDcard. In the long term I think it could be possible for the community to assemble Tizen infrastructure that automatically builds bootable SDcard tizen images to save time, but I’ll detail the whole process here in the meantime.

The Short and Easy Path

For your convenience, you can download an image of the build I’ll be describing here (md5=0d21e2716f67a16086fdd2724e7e11f1). It’s a binary image of the latest Tizen weekly development version (plus the latest IoTivity build too) prepared for the ARTIK10. All you have to do is flash it to the SD card, switch SW2/1 to on and SW2/2 to off, setup USB link to change a couple of U-Boot variables (set rootdev 1 ; set rootpart 3 ; boot ) as explained later in this tutorial.

# lsblk
disk=/dev/sdTODO
file=tizen-common-artik_20160627.3_common-wayland-3parts-armv7l-artik10.qcow2
# time qemu-img convert -p "${file}" "${disk}"

If you want to take the long road, or you want to do this for the ARTIK5, follow the rest of this guide; it will explain how to build Tizen and IoTivity to run on the ARTIK.

Download Tizen

Development for the Tizen project is a continuous process, the latest version can be downloaded here.

In the images/arm-wayland/ sub folder you’ll need to download 2 archives, the first is the boot image, which is different based on whether you’re using the ARTIK5 or ARTIK10. This image includes kernel and modules and the bootloader. The main difference between the ARTIK5 and ARTIK10 images is that U-Boot parameters are written at different media offsets.

I’m using the ARTIK10 for this guide, so I downloaded the tar.gz file found here. If you want to save bandwidth and time, it’s possible to grab a headless image archive tizen-common-artik_YYYYMMDD.*_common-headless-3parts-armv7l-artik.tar.gz.

If you own an ARTIK5, download the image from here; the ARTIK1 is totally different and it’s unlikely the same Tizen 3 codebase will be ever supported.

Prepare the SD Card

To write data to SD card, I’ll use the helpful sdboot script to handle the partitioning, formating and copying tasks that would be done manually using dd.

git clone https://github.com/tizenteam/sdboot -b master 

Insert the SD card into the host computer and identify the device node:

lsblk
disk=/dev/sdX # replace X with matching letter

Next, partition the SD card (8GB is minimal requirement), and format no less than 6 partitions.

sudo bash -x ./mk_sdboot.sh -f "$disk"

In the repo that was cloned earlier there is tizen-sd-bootloader-artik10.tar.gz; this contains early stages of the signed bootloader (bl1.bin, bl2.bin and ARM Trust Zone Software tzsw.bin). Note: don’t be confused by the “tz” in “twsw.bin” it means ARM TrustZone software not Tizen. The general purpose is to establish a chain of trust to ensure software integrity. The general purpose is to establish a chain of trust to ensure software integrity. U-boot.bin and its parameters file params.bin will be overridden later, and uInitrd, while not totally mandatory, will be helpful to setup systemd and mount the modules partition.

Use the mk_sdboot.sh helper script to write these files at the specific offets (Seek by 1231 for artik10’s U-Boot params file):

sudo bash -x ./mk_sdboot.sh -w /dev/sdb  tizen-sd-bootloader-artik10.tar.gz

Now, the SDcard should be able to launch U-Boot’s shell, so the next step is to prepare the operating system. Copy the Linux kernel to the 1st partition and its modules to the 2nd, and override the copied uboot and params just before the 1st partition:

sudo bash -x ./mk_sdboot.sh -w "$disk" tizen-*-boot-armv7l-artik10.tar.gz

Now, you can try to boot the kernel if you want, but let’s also dump Tizen’s rootfs to our SD card’s 3rd partition. Along with this, 2 other partitions are copied too: user and systemd-data.

sudo bash -x ./mk_sdboot.sh -w "$disk" tizen-*-3parts-armv7l-artik.tar.gz 

The device should now be capable of booting into Tizen.

Boot Tizen

For the purpose of this guide, I’m going to assume you’ve already booted your ARTIK with an existing OS (Fedora) or others (Ubuntu, Yocto) and know how to setup your debug link.

 

 

Power up the ARTIK10.

screen /dev/ttyUSB0 115200

U-Boot 2012.07-g801ab1503-TIZEN.org (Jun 20 2016 - 15:27:02) for ARTIK10

CPU: Exynos5422 Rev0.1 [Samsung SOC on SMP Platform Base on ARM CortexA7]
APLL = 800MHz, KPLL = 800MHz
MPLL = 532MHz, BPLL = 825MHz

Board: ARTIK10
DRAM:  2 GiB
WARNING: Caches not enabled

TrustZone Enabled BSP
BL1 version: /
VDD_KFC: 0x44
LDO19: 0x28

Checking Boot Mode ... SDMMC
MMC:   S5P_MSHC2: 0, S5P_MSHC0: 1
MMC Device 0: 7.4 GiB
MMC Device 1: 14.6 GiB
MMC Device 2: MMC Device 2 not found
In:    serial
Out:   serial
Err:   serial
rst_stat : 0x100
Net:   No ethernet found.
Hit any key to stop autoboot:  0 

Hit any key to stop and get a shell, if you don’t, U-Boot will try to boot the OS from the eMMC. Once you are in UBoot’s shell, change some variables temporarily:

ARTIK10 # version
U-Boot 2012.07-g801ab1503-TIZEN.org (Jun 20 2016 - 15:27:02) for ARTIK10
gcc (Tizen/Linaro GCC 4.9.2 2015.02) 4.9.2
GNU ld (GNU Binutils) 2.25.0 Linaro 2015_01-2

ARTIK10 # env default -f ;
ARTIK10 # set rootdev 1 ; set rootpart 3 ; boot 

In the next step of the boot process, the kernel, device tree and rootfs are loaded and executed:

reading zImage
5339682 bytes read in 67299 ms (77.1 KiB/s)
reading exynos5422-artik10.dtb
69754 bytes read in 117983 ms (0 Bytes/s)
reading uInitrd
1353683 bytes read in 29687 ms (43.9 KiB/s)
## Loading init Ramdisk from Legacy Image at 43000000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    1353619 Bytes = 1.3 MiB
   Load Address: 00000000
   Entry Point:  00000000

Starting kernel ...

[    0.092805] [c0] /cpus/cpu@0 missing clock-frequency property
(...)
[    0.093269] [c0] exynos-snapshot: exynos_ss_init failed
[    0.335618] [c5] Exynos5422 ASV : invalid IDS value
(...)
Welcome to Tizen 3.0.0 (Tizen3/Common)!
(...)

Login to Tizen

The first boot will take a bit longer than usual, but eventually a prompt will appear that will allow you to login as root with “tizen” as the password:

Welcome to Tizen 3.0.0 (Tizen3/Common)!
(...)
localhost login: 
Password: 

# cat /etc/os-release 
NAME=Tizen
VERSION="3.0.0 (Tizen3/Common)"
ID=tizen
VERSION_ID=3.0.0
PRETTY_NAME="Tizen 3.0.0 (Tizen3/Common)"
ANSI_COLOR="0;36"
CPE_NAME="cpe:/o:tizen:tizen:3.0.0"
BUILD_ID=tizen-common-artik_20160627.3_common-wayland-3parts-armv7l-artik

# cat /proc/cmdline 
console=ttySAC3,115200n8 root=/dev/mmcblk1p3 rw rootfstype=ext4 loglevel=4 asix.macaddr=d2:40:??:??:??:?? bd_addr=C0:97:??:??:??:??

# cat /proc/version 
Linux version 3.10.93-3.1-arm-artik10 (abuild@w17) (gcc version 4.9.2 (Tizen/Linaro GCC 4.9.2 2015.02) ) #1 SMP PREEMPT Mon Jun 27 16:54:57 UTC 2016

# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk1p3        2.0G  726M  1.2G  38% /

Hotfix

I noticed a critical bug that can be worked around for now. Some daemons are causing damage to the root filesystem after a short period (less than 5 minutes), I suspect they could generate too much output and fill our low disk space, this is something that needs to be investigated. As a temporary solution, they should be stopped as soon as possible:

# systemctl stop deviced ; systemctl stop resourced ;
# systemctl disable deviced ; systemctl disable resourced

To make sure they won’t be re installed / restarted, they need to also be renamed:

# mv /usr/bin/deviced /usr/bin/deviced.orig
# mv /usr/bin/resourced /usr/bin/resourced.orig
# systemctl status deviced
Active: inactive (dead) since Mon 2016-07-25 10:05:09 PDT; 25s ago

Then, make sure the modules partition is mounted and matches the kernel version:

ls -l  /lib/modules/$(uname -r)/modules.dep
-rw-r--r-- 1 root root 21574 Jun 27 09:56 /lib/modules/3.10.93-3.1-arm-artik10/modules.dep

If not you aren’t using uInitrd, you’ll have to tweak fstab.

Connect to the Network

Check to make sure the network is working and the device has an IP address assigned to it:

ifconfig -a
eth0: flags=-28605  mtu 1500
        inet 192.168.0.42  netmask 255.255.255.0  broadcast 192.168.0.255

If it doesn’t, it can be set it up manually after loading the AX8817X USB NIC’s driver:

# modprobe -v asix

insmod /lib/modules/3.10.93-3.1-arm-artik10/kernel/drivers/net/usb/usbnet.ko 
insmod /lib/modules/3.10.93-3.1-arm-artik10/kernel/drivers/net/usb/asix.ko macaddr=d2:40:??:??:??:??

The LAN’s DHCP server should then assign an IP address to the device.

Install Packages

The headless image should already have zypper installed, it will be used for this section. If for some reason it’s not part of the image, it’s possible to use sdb to install it. This is outside the scope of this article, but if you have questions, feel free to post them to the comment section.

First, add the remote repos:

# zypper lr
Warning: No repositories defined.
Use the 'zypper addrepo' command to add one or more repositories.

# zypper addrepo http://download.tizen.org/live/Tizen:/Base/arm/Tizen:Base.repo
# zypper ar http://download.tizen.org/live/Tizen:/Common:/3.0b:/artik/arm-wayland/Tizen:Common:3.0b:artik.repo

Now it’s possible to install packages and upgrade the distro to latest snapshot.

# zypper in screen openssh
# zypper up

Take IoTivity for a Spin.

What’s next? Many people have expressed interest in using IoTivity on new platforms like Tizen, so let’s take a look at some of the IoTivity apps.

# zypper in iotivity-test iotcon-test 
# downgrade if needed
# rpm -ql iotivity-test

The binary image I shared at the beginning of this article contains the recently-released iotivity-1.1.1. I built it locally from sources using GBS on the 1.1.1 git tag with security enabled. The example apps must be run in the same directory where *.dat files are stored. Here are some instructions to launch a sample app I described in my previous article on IoTivity on ARTIK:

ls /usr/bin/*.dat
/usr/bin/oic_svr_db_client.dat
/usr/bin/oic_svr_db_server.dat
cd /usr/bin/ ; /usr/bin/simpleserver 2 
# in an other terminal :
cd /usr/bin/ ; /usr/bin/simpleclient 1 

What’s Next?

I’m going to continue hacking away at Tizen on my ARTIK10, stay tuned for more articles about developing on these platforms. Also check upcoming Tizen Community Online Meeting, a live chat about ARTIK is planned this fall, see you there.

 

How to Run IoTivity on ARTIK with Yocto

Samsung ARTIK is described by its developers as an end-to-end, integrated IoT platform that transforms the process of building, launching, and managing IoT products. I first saw one a year ago at the Samsung VIPEvent 2015 in Paris, but now there is an ARTIK10 on my desk and I would like to share some of my experiences of it with you.

In this post, I will show how to build a whole GNU/Linux system using Yocto, a project that provides great flexibility in mixing and matching components and customizing an environment to support new hardware or interesting software like IoTivity. If you’re looking for Tizen support, it’s already here (check at bottom of this article), but this post will focus on a generic Linux build.

Many of the board’s features I will be covering in this article are briefly introduced in the following video:

There are 3 ARTIK models on the market: ARTIK 1 is MIPS based system with 1MB of RAM while ARTIK 5 and 10 are powerful ARM systems based on Exynos System on Module. This article covers the ARTIK 10 and it can easily be adapted to the ARTIK 5, but not the ARTIK 1.

According to the specifications, the ARTIK 10 has an 8 Core CPU (4 Cortex-A7 and 4 Cortex-A15), 2GB of RAM, and a GPU (Mali T628) for multimedia needs. Since the ARTIK family is targeted for Internet of Things use cases, there are also a lot of connectivity controllers (Wired Ethernet, Wi-Fi : IEEE802.11a/b/g/n/ac, Bluetooth 4.1 + LE, Zigbee/Thread) as well as security elements (ARM TrustZone, TEE) which are mandatory for a safe IoT.

Unboxing and Booting the ARTIK 10

In the box you’ll find 4 antennas, a micro USB cable, and power supply (5V*5A with center positive plug). Warning: some devices like Intel NUC use the same 5.5 x 2.1mm power supply barrel, but at 12V. It’s a good idea to label power supply connectors if you have a bunch lying around because plugging in 12V+ will probably brick your ARTIK.

Setup the Debug Port

Once you plug the USB cable into the ARTIK, 2 blue lights will turn on and on your host side a serial port device will appear (even if device is powered off):

$ lsusb
Bus 002 Device 012: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

dmesg | tail
usb 2-1.5.2: new full-speed USB device number 12 using ehci-pci
usb 2-1.5.2: New USB device found, idVendor=0403, idProduct=6001
usb 2-1.5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.5.2: Product: FT232R USB UART
usb 2-1.5.2: Manufacturer: FTDI
usb 2-1.5.2: SerialNumber: ????????
ftdi_sio 2-1.5.2:1.0: FTDI USB Serial Device converter detected
usb 2-1.5.2: Detected FT232RL
usb 2-1.5.2: FTDI USB Serial Device converter now attached to ttyUSB0

$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jun  2 15:11 /dev/ttyUSB0

As you can see the device is owned by root and belongs to the dialout group, so check if your user is in this group too (groups | grep dialout), then you can use your favorite serial terminal (minicom, picocom) or GNUscreen.

screen /dev/ttyUSB0 115200

That’s it!. If you’re on Windows, enjoy this Cybercode twins’ video to learn a bit about how to get setup.

Ready For Your First Boot

Turn off the device by pressing on the left side of the “POWER SW” 2 states button. Then, connect the power supply, wait about 10 seconds, and hold the SW3 POWER switch for a couple of seconds. After this, U-Boot’s log should be printed in the terminal.

Mine came loaded with the reference system based on Fedora 22. To use this, you can login as root:root and you’ll have at least 13G free (of 16G) to work. Here is a reference file from the flashed OS on the eMMC:

# cat /etc/artik_release

RELEASE_VERSION=1020GC0F-3AF-01Q0
RELEASE_DATE=20160308.225306
RELEASE_UBOOT=U-Boot 2012.07
RELEASE_KERNEL=3.10.93

Since we’ll be setting up a different operating system, I prefer to avoid touching this supported system and I’ll leave it to use as a reference to compare hardware support. The plan is to work on a removable microSD card and not change the eMMC at all.

Boot From an SD Card

Like many other SoC’s like the ODROID devices, booting from a microSD card is supported, but it requires a bit of manual intervention. You first need to configure it using micro switches “SW2” on the left, located between the debug and USB3 ports.

The switch block may be covered with tiny piece of plastic tape, remove it carefully with a toothpick and move both switches from the left (OFF) position to the right where “ON” is printed.

To try my experimental, compressed image, download demo-image-artik10-20160606081039.rootfs.artik-sdimg.qcow2 (md5:12c64d6631482f90d45a0d015bea5980) from our file server and copy to your microSD card using qemu-utils:

# lsblk
disk=/dev/sdTODO
file=demo-image-artik10-20160606081039.rootfs.artik-sdimg.qcow2
# time qemu-img convert -p "${file}" "${disk}"

As you did earlier, power the device off, connect the USB cable, insert the microSD card, switch it on, wait for a few seconds, and finally hold the micro switch for a couple of seconds. U-Boot should run through its configuration and some verbose output should be printed on the serial console:

U-Boot 2012.07 (Jun 06 2016 - 10:42:48) for ARTIK10

CPU: Exynos5422 Rev0.1 [Samsung SOC on SMP Platform Base on ARM CortexA7]
APLL = 800MHz, KPLL = 800MHz
MPLL = 532MHz, BPLL = 825MHz

Board: ARTIK10
DRAM:  2 GiB
WARNING: Caches not enabled

TrustZone Enabled BSP
BL1 version: ?/???
VDD_KFC: 0x44
LDO19: 0x28

Checking Boot Mode ... SDMMC
MMC:   S5P_MSHC2: 0, S5P_MSHC0: 1
MMC Device 0: 7.4 GiB
MMC Device 1: 14.6 GiB
MMC Device 2: MMC Device 2 not found
In:    serial   
Out:   serial   
Err:   serial   
rst_stat : 0x100
Net:   No ethernet found.
Hit any key to stop autoboot:  0
[Fusing Image from SD Card.]
(...)
reading zImage
5030144 bytes read in 32570 ms (150.4 KiB/s)
reading exynos5422-artik10.dtb
71014 bytes read in 31067 ms (2 KiB/s)
## Flattened Device Tree blob at 40800000
   Booting using the fdt blob at 0x40800000
   Loading Device Tree to 4ffeb000, end 4ffff565 ... OK

Starting kernel ..
(...)

And in the end you’ll get a login prompt for root without password:

Poky (Yocto Project Reference Distro) 2.0.2 artik10 /dev/ttySAC3

artik10 login: root

root@artik10:~# cat /proc/version 
Linux version 3.10.93 (philippe@WSF-1127) (gcc version 5.2.0 (GCC) ) #1 SMP PREEMPT Mon Jun 6 10:39:42 CEST 2016

root@artik10:~# cat /proc/cmdline 
console=ttySAC3,115200n8 root=/dev/mmcblk1p2 rw rootfstype=ext4 loglevel=4 rootdelay=3

Now you are ready for the section on building your own image, but if you really want to make sure everything is working, Canonical supports ARTIK so you can use an Ubuntu snappy image. For reference, I tested artik10-snappy-20160317.img.tar.xz and it reported the following for its Kernel:

Linux version 3.10.9-00008-gb745981-dirty (u@u-ThinkPad-T450) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #7 SMP PREEMPT Thu Mar 10 10:06:16 CST 2016

Build Your Own Image with meta-artik

First we start with Poky: the Yocto reference distro, because it’s the quickest way to reach today’s goal. As with all Yocto targets, you first need to identify a Board Support Package (BSP) layer that collects all the special software needed for this family of hardware. As far as I know there is no official Yocto layer for ARTIK.

I’ve known about meta-exynos but I also noticed the meta-artik community layer from ResinIo; they spoke about ARTIK BSP at the latest Samsung Developer Conference (SDC2016):

What really matters in this set is the u-boot-artik and linux-exynos recipes to fetch sources. So we’re going to make use of my small contribution to produce standalone bootable sdcard images in meta-artik’s master branch.
The patch adds a new class for SD card output; the black magic is that U-Boot params should be dumped to different places (0x00080e00 (1031*512) for ARTIK5 and 0x00099e00 (1231*512) for ARTIK10), if not done I’ll try to adapt this for Tizen too.

Let’s clone Poky, add the layer to your conf file, and build a regular image.

$ git clone -b jethro http://git.yoctoproject.org/git/poky
$ cd poky
$ git clone -b master https://github.com/resin-os/meta-artik
$ . ./oe-init-build-env

With the recipe in place, you need to tell the environment to look for it. For this, edit the bblayers.conf file from the base setup (this file will be in build/conf/ underneath your top level directory) and add a line to the BBLAYERS stanza (there’s no need to add to BBLAYERS_NON_REMOVABLE, that doesn’t apply to this build). Using the format of the base post, the line would look like this:

$ cat conf/bblayers.conf

RELATIVE_DIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../../..')}"
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ${RELATIVE_DIR}/poky/meta \
  ${RELATIVE_DIR}/poky/meta-yocto \
  ${RELATIVE_DIR}/poky/meta-yocto-bsp \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  ${RELATIVE_DIR}/poky/meta \
  ${RELATIVE_DIR}/poky/meta-yocto \
  "

BBLAYERS += "${RELATIVE_DIR}/poky/meta-artik"

Then, build the image:

$ MACHINE=artik10 bitbake core-image-minimal

When this finishes, write the image to the SD card:

lsusb # list of disks devices
disk=/dev/sdTODO # update device for sdcard
dd if=tmp/deploy/images/artik10/core-image-minimal-artik10.artik-sdimg bs=32M oflag=sync of=$disk

Adding IoTivity

IoTivity is an open source framework that enables effective device-to-device connectivity for the Internet of Things. It implements the emerging standards from the Open Connectivity Foundation (OCF was formerly known as OIC, and the specified protocols still use the oic name, as does the layer described below).

The layered approach of Yocto makes it easy to add components, as long as descriptions exist for them. Otherwise you need to write your own descriptions, which is not too hard. To add IoTivity, add the meta-oic layer:

$ cd ../../poky
$ git clone -b 1.1.0 http://git.yoctoproject.org/cgit/cgit.cgi/meta-oic

Next, add it to previous file (./build/conf/bblayers.conf)

BBLAYERS += "${RELATIVE_DIR}/poky/meta-oic"

We also want to add some of the IoTivity packages into the built image; edit build/conf/local.conf to add these:

# IoTivity
IMAGE_INSTALL_append = " iotivity iotivity-resource iotivity-service"
# To get the example apps, include these as well:
IMAGE_INSTALL_append = " iotivity-resource-samples iotivity-service-samples"

Finally, build it :

MACHINE=artik10 bitbake core-image-mininal

Like before, copy this image to the SD card and boot it up the normal way.

Trying out IoTivity

Once you have installed the example packages, you can find apps to try things out. This is probably more interesting with two machines running IoTivity, so you can have a distinct client and server device, but it is possible to run both on the same machine.

In /opt/iotivity/examples/resource/cpp/ you will see these files, which make up client/server pairs – the names are descriptive:

ls /opt/iotivity/examples/resource/cpp/

OICMiddle              groupclient            simpleclient
devicediscoveryclient  groupserver            simpleclientHQ
devicediscoveryserver  lightserver            simpleclientserver
fridgeclient           presenceclient         simpleserver
fridgeserver           presenceserver         simpleserverHQ
garageclient           roomclient             threadingsample
garageserver           roomserver

Start the simple server, which will emulate an OCF/OIC device, and in this case, a light:

$ cd /opt/iotivity/examples/resource/cpp/ ; ./simpleserver

Usage : simpleserver 
    Default - Non-secure resource and notify all observers
    1 - Non-secure resource and notify list of observers

    2 - Secure resource and notify all observers
    3 - Secure resource and notify list of observers

    4 - Non-secure resource, GET slow response, notify all observers
Created resource.
Added Interface and Type
Waiting

Now start the simple client in the another shell session:

$ cd /opt/iotivity/examples/resource/cpp/ ; ./simpleclient

---------------------------------------------------------------------
Usage : simpleclient 
   ObserveType : 1 - Observe
   ObserveType : 2 - ObserveAll
---------------------------------------------------------------------



Finding Resource...
Finding Resource for second time...
In foundResource
In foundResource
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774In foundResource
/oic/d for the first time on server with ID: 4126ec5c-16ce-4b9b-84e6-15ad6e268774
DISCOVERED Resource:
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774/oic/p for the first time on server with ID:         URI of the resource: /oic/d4126ec5c-16ce-4b9b-84e6-15ad6e268774

DISCOVERED Resource:
        URI of the resource: /oic/p
Found resource 4126ec5c-16ce-4b9b-84e6-15ad6e268774/a/light for the first time on server with ID:       Host address of the resource: coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:
        Host address of the resource:           oic.wk.d
        List of resource interfaces:
4126ec5c-16ce-4b9b-84e6-15ad6e268774            oic.if.baseline
                oic.if.r
coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:

                oic.wk.p
        List of resource interfaces:
DISCOVERED Resource:            oic.if.baseline
        URI of the resource: /a/light

                oic.if.r
        Host address of the resource: coap://[fe80::b82b:e6ff:fe30:8efd]:44475
        List of resource types:
                core.light
                core.brightlight
        List of resource interfaces:
                oic.if.baseline
                oic.if.ll
Getting Light Representation...

The OIC specifications describe a RESTful model of communications, where everything is modeled as resources and web-style commands are used to operate on representations of these resources, such as GET, POST, PUT, etc. The communication model is called CRUDN (Create, Retrieve, Update, Delete, Notify). In this example, the IoTivity server sets up resources to describe the (emulated) OIC device. Once the client starts, it tries to discover if there are interesting resources on the network using a multicast GET; the server responds to this with the resources it is hosting. In our example, there is a light resource and a brightlight resource (meaning the light that can have brightness controlled). At this point, the two can speak to each other with the client driving the conversation.

We can see the client getting a representation of the state of the emulated light:

GET request was successful
Resource URI: /a/light
        state: false
        power: 0
        name: John's light

It then creates a state on the server that has a power value of 15.

Putting light representation...
PUT request was successful
        state: true
        power: 15
        name: John's light

Next the client tries to update the light state to a value of 55:

Posting light representation...
POST request was successful
        Uri of the created resource: /a/light1
Posting light representation...
POST request was successful
        state: true
        power: 55
        name: John's light

After this, the client sets up an observe on the server so it will be notified of state changes.

Observe is used.

Observe registration action is successful

The light power is updated in steps of 10, with the client reporting to via prints every time it receives a notification. A typical event looks like:

OBSERVE RESULT:
        SequenceNumber: 0
        state: true
        power: 55
        name: John's light

Meanwhile, we can watch the server report the requests it receives and the actions it takes. Once the light power reaches a certain level and the client sees that the last change has been observed, the connection is shut down.

This is just a basic sample of IoTivity in operation, have fun experimenting with this brand new technology for the Internet of Things! There is more to be done from this state, specifically on the connectivity domain such as adding Bluetooth, BTLE, or LPWAN, since these are what matter the most for IoTivity.

What’s Next?

We can expect that Tizen support will improve soon as it’s becoming one of the reference board.

IoT applications have an incredibly wide range of uses; here is an example of work we’ve done within the automotive context:

Feedback is also welcome if you’d like us to explain anything with more depth, such as Tizen support, Tizen OBS/GBS images, or Tizen Yocto, feel free to keep in touch.

[wp_biographia user="pcoval"]

[wp_biographia user="mats"]

ARTIK is a registered trademark of Samsung.

OSG, OCF, & An Automotive Fortnight!

The Samsung Open Source Group is playing an active role in the promotion and adoption of IoT standards across multiple domains. Samsung understands the importance of openness and collaboration to realize the full potential of IoT. One of the key promises we’ve made,  is to be open and collaborative in our approach to delivering products and solutions to our customers. This was a core part of the Samsung strategy, as explained in the following video.

Samsung has remain committed to this approach and continued to deliver on the promise, year after year.

Based on these principles the Open Connectivity Foundation (OCF), a global consortium of leading companies (~170 and growing) focused on creating a standard for interoperable devices and services was founded in 2014. The OCF approach has three key deliverables:

  1. An Open Specification: Open Connectivity Foundation
  2. An Open Source Implementation: IoTivity
  3. A membership driven certification program:  OCF certification

Through this approach, OCF has created an ecosystem where device manufacturers, IT service providers, and application developers can target their existing devices, services, and apps to a massive potential consumer base. This program has continued to gain more members and build momentum. Automotive is one key target of OCF and IoTivity, and the Open Source Group has been busy solving some important issues in this domain.

This post will cover a handful of presentations we’ve given recently to help spread the message. For some context, check out our overview of some of our recent activities with IoTivity and automotive functionality.

GENIVI & OCF Demo

A demonstration of GENIVI and OCF was presented at the recent GENIVI all member meeting in Paris. This technical session demonstrated how IoTivity can be used to connect automotive systems to OCF devices. This was a joint effort between Jaguar Land Rover, GENIVI, and Samsung.

Extra Resources:

Technical talk at the AGL AMM in Japan, 2016

Another talk worth mentioning is one given at the Automotive Grade Linux (AGL) All Members Meeting (AMM) that was held last February in Tokyo, Japan. It describes plans in the community to provide OCF support to a Yocto-based system.

Additional resources:

How to: IoTivity on Tizen presented at OpenIoT 2016

The combination of Tizen, IoTivity, and Yocto is proving to be a very powerful platform for building a wide range of consumer devices. Some hints were shared about IoTivity integration on commercialized Tizen devices with Tizen:IVI at OpenIoT in San Diego, CA.

Additional resources:

CampOSV: First Vehicle Hackathon, Rennes France

CampOSV is a community event in Rennes, France about what can be done on open R&D platforms. We demonstrated how Tizen and IoTivity can be used to create a “libre, connected car” through a proof of concept.

Additional resources:

OSIS2016 : Open Source Innovation Spring at IoT day, Paris

Philippe gave a talk at IoT Day in Paris, France about using IoTivity and Tizen to create IoT devices and prototypes using the RaspberryPI Zero. This talk offered more technical details about creating a GPS map that integrated a smart watch with an in-car dash.

Conclusion

The overall goal of these activities is for Samsung to examine the multiple approaches for collaboration with existing open source communities and distributions in the automotive space. GENIVI and AGL have built incredible communities that follow different approaches, and as part of expanding OCF into the automotive domain we would like to bring OCF and IoTivity to interested members in both of these communities. We’d like people to consider the adoption of an IoT standard that will be mutually beneficial to both OCF and the open source automotive pioneers. In the coming weeks we will be submitting patches into public repositories of GENIVI and Automotive Grade Linux, for these demos.

We have received tremendous response from a broad technical community including W3C, Genivi and AGL members and will continue to collaborate going further. We encourage you to checkout the information and links and let us know if you’re interested in collaborating with us.

[wp_biographia user="sanjeev"]

[wp_biographia user="pcoval"]

IoTivity is Getting Ready for Automotive

Samsung has recently intensified its focus on improving the driving experience with the launch of Connect Auto. As a coincidence, I tried to put together different efforts from our group to into an open connected car experiment.

Check out this video which shows a DIY Tizen fan that’s controlled from an Automotive Linux system and Tizen TM1 mobile device:

It’s All About Interoperability

It might look a bit over-engineered with all of the devices in this demonstration, but the purpose is to validate communication between devices on a network (WiFi, BT, BLE) in various contexts. Of course, it’s possible to adapt the DIY fan to use an automatic gate mechanism or something else to interact with the driver, or it could even use cloud services that ensure the necessary level of security.

IoTivity is Getting Ready for Automotive - WHise0EeSnD20

Interoperability is the key word here, I believe we’re headed in the right direction following the recent Open Connectivity Foundation announcement:

“Open Connectivity Foundation Brings Massive Scale to IoT Ecosystem : The OCF unifies the entirety of the former Open Interconnect Consortium with leading companies at all levels – silicon, software, platform, and finished-goods – dedicated to providing this key interoperability element of an IoT solution.”

IoTivity and Automotive Grade Linux

If you’re interested in trying this out, it’s easy to rebuild the AGL distro with IoTivity included using a single make command, after cloning my meta-yocto-demos helper project. Check instructions details on this dedicated page. If you happen to be attending the Automotive Grade Linux Member Meeting, there will be an Open Interconnect Consortium & AGL presentation where you can learn more.

IoTivity is Getting Ready for Automotive - QGwKcZ9SuNxxC

Yocto as the Base of GENIVI and Tizen

I’d like also to add that the Yocto project has become quite popular among open source automotive projects. Personally, I like it because its design encourages cooperation between operating systems, and it has the potential to become a point of convergence. For example, I managed to ship meta-oic into the GENIVI demo platform without any adaptation, I suppose it’s likely the same for any OpenEmbedded-based distro.

The final item of the demo is the IoTivity server running on a Tizen-powered RaspberryPI 1, for more details on this system, check out the presentation I gave about Tizen Yocto at FOSDEM earlier this year with current maintainer Leon Anavi:

More to Come

If you’re curious about OSVehicle, and willing to contribute to an open source, connected car, join me in the OSVehicle forum. As you can observe from this example, Yocto is a common denominator of these systems and it makes IoTivity ready to reach many devices including automotive, smart homes, and more. I’m hoping to begin work on adding IoTivity support to GENIVI and AGL soon, which could help bring great features like car-to-car connectivity.

IoTivity is Getting Ready for Automotive - iotivity-minnowmax.gif

Last but not least, I’d like to invite you to my talk  that explains How to use IoTivity on Tizen at the OpenIoT Summit in in April; don’t miss the other sessions from Samsung speakers.

Spend Some Time With the Tizen Community at FOSDEM 2016

For the 5th year in a row, the Tizen community will meet at FOSDEM: one of the most important free and open source software conferences in Europe. Members of the Tizen community from all over the world, including South Korea, Poland, UK, Bulgaria, and France will converge  on January 31 and February 1, 2016 at ULB Solbosch Campus, Brussels, Belgium.

Here’s what you can expect from the Tizen community, this year:

  • Meet Tizen developers from around the world for discussions.
  • Interact with demos at the EFL/Tizen booth.
  • Dine with Tizen developers at the community dinner.
  • Learn and discover about free and open source software.

Join Our Casual Dinner Meeting!

If you are interested in Tizen presence at the conference, just bookmark Tizen’s wiki FOSDEM page and join us.

There you will find details about latest news and plans including the Tizen community dinner that will occur on the evening of Saturday, January 30, 2016.  Please register on TizenExperts before this event. It is open to anyone but places are limited. Also note that participants will need to pay for their own food. This is a community event, so sorry there won’t be any free beer, but there will certainly be unlimited free speech!

Spend Some Time With the Tizen Community at FOSDEM 2016 - bxl-14020008
Brussels is a wonderful location for a conference.

Demo Time!

Many of the community members will be found at the EFL/Tizen booth (K building) throughout the day; there you will also be able to see and interact with many devices that run Tizen including the RaspberryPI 1 (ARMv6), RaspberryPI 2 and more advanced devices.

Catch Some Great Talks!

The list of accepted talks has net yet been published in full, but here is a teaser talks that will be presented about Tizen and related topics.

Don’t miss these presentation about Tizen Core components:

Tizen’s primary use-case is for IoT, and you can expect many interesting talks about this subject; some of which closely relate to Tizen:

Finally, here are some other projects that are closely related to Tizen:

Here are a handful of other interesting talks:

Many more will appear on the schedule page as it is update. As a primer, check out one of the Tizen talks from last year. FOSDEM is a great experience for anyone interested in free and open source software, and we hope you will seek out the Tizen community while you are there!

Source: Tizen Wiki