The netPI is a ruggedized Raspberry Pi 3 platform for customizable Edge automation applications. netPI‘s single circuit board contains the Raspberry Pi 3 circuitry along with Hilscher’s multiprotocol industrial network SoC netX.

With expandable hardware and freely programmable software netPI manifest itself as an open ecosystem for realizing individual "Internet of Things" and "Industry 4.0" automation solutions of the IT/ OT Edge sector. netPI pursues the principle of "open innovation" with collaborative added value.

Hilscher provides the base platform with an environment designed for the active expansion of the product's functionality, the customer completes in accordance to his own discretion in software or hardware. The goal is to bind external and existing knowledge to netPI and to jointly increase the total system value for both parties involved.

netPI is a product developed by Hilscher and Element14, the manufacturer of the standard Raspberry Pi 3. From a hardware perspective netPI's PCB includes the same circuitry and components you know from Pi 3 already except the composite audio/video output jack and DSI display port (we felt they make no sense on an industrialized product). The CSI camera connector is available on the PCB but not populated on the PCBA. In summary netPI is 99% compatible with a Pi 3 and 100% if you don't use audio/video and DSI port.

We offer a bunge of Industrial Network Controllers named netX since years with great success. The netPI design additionally includes the netX51 SoC made for Fieldbus or Industrial Ethernet communications as an I/O slave/device/adapter. netPI's focus is connecting the two worlds IT and OT both communicating with state-of-the-art industrial Ethernet and this is why netPI comes with two RJ45 Ethernet ports extra driven by netX51.

netX51 is multi-protocol capable and supports today's most popular Industrial Ethernet protocols such as Profinet, EtherCAT, EtherNet/IP any many more. A simple firmware loading procedure changes from one protocol to the other in seconds.

Accessing netX51's interface enables access to factory automation networks consisting of a controlling PLC typically with underlying peripheral I/O devices connecting to the sensors and actuators. netX51 will integrate in these networks as I/O unit as well and exchanges data from and to the network with a host application.

Linux:

When it came to netPI we decided to use a Yocto project based customized version of Linux. The Yocto community helps with templates, configuration files, examples all those who want to port Linux with an own "flair" onto their embedded hardware. The kernel we are currently using is a version 4.9.x or higher with applied RT-patch and installed AppArmor security framework.

Docker:

On top of Linux the software Docker is running in the version 17.06.0-ce (2017-06-28) or higher. Docker allows you to run applications in isolated containers without concerns you break or brick netPI main system.

Edge Gateway Manager:

The Edge Gateway Manager (EGM) is netPI's web GUI navigator. From there you can easily navigate with clickable tiles to the different installed netPI applications such as Control Panel, Docker and more.

Because of security reasons applications and services having immediate affect on netPI's connectivity are disabled by default. They need to be activated in the Control Panel under the section Services before they can be used. Tiles of disabled applications as the Docker tile in the picture above are greyed out.

Portainer.io:

In order to deploy, run and maintain containers on netPI the web GUI front end portainer.io is installed in the version 1.12.4 or higher.

netPI can be accessed through a standard Web browser. Its single 10/100Mbit Ethernet port is configured to receive an IP address over a DHCP server by default. So netPIs IP address is not a fixed one and depends on your local IP network setup and DHCP server that is connected to it. The DHCP server has to be either active during netPI's boot-sequence already or can be connected at later times to provide an IP address to netPI.

Next to reaching netPI over its IP address "https://<netPIs IP address>" it supports additionally identification over the socalled NetBIOS protocol. Providing its "Hostname" by this method is a friendly means of identifying netPI's IP address. On Windows for example you can use the "View Network Computers and Devices" command to scan for all Hostnames providing devices. (make sure you have enabled the network discovery option). It will show all connected netPIs like the following picture shows:

You can click on these icons directly to open the device's landing pages in a web browser.

netPI's Hostname is a combination of the two letters "NT" plus its unique "MAC address" and comes printed on netPI's label. In the example above it is "NTB827EB861EF7" for a device having a MAC address of b8:27:eb:86:1e:f7. So if you would enter this Hostname in your brower address bar along with the HTTPS access method in a string like "https://NTB827EB861EF7" you would get access to your netPI without knowing it's IP address.

Once you reach netPIs landing page click on the Control Panel tile and do a login with the following credentials:

user: admin

password: admin

After you logged in the first time netPI will urge you to change the password to your own. Please take note of this set password and treat it with care since you are getting administrator rights with this login granting you access to any netPI's web page and settings. You can change this password in netPI's Control Panel at any time you are logged in as administrator.

The Docker community maintains a web site at Docker Hub providing space for up and downloading Docker images for anyone in so-called registries.

Everybody can participate and create his own private, public and commercial registry there. For netPI we created a registry under Docker Hub as well at netPI registry. There you find example container images prebuilt by us and compatible with netPI (and Pi 3).

Third parties have recognized Pi 3 as a performant platform too like the company resin.io and provide containerized software on Docker Hub to the public too. If you enter the search term resin.io in Docker Hub's search box you get several images of different types compatible with Pi 3 and hence with netPI downloaded by the community 10K times and more already.

The only precondition for other images to run on netPI (or Pi 3) is that they have been built for ARM architecture based platforms. There are other images compiled for x86 compatible platforms which cannot run on netPI.

An investigation started by IBM and published by IEEE investigates the performance of containerized software under Docker and concludes that performance losses in comparison to the native system are extremely small and therefore negligible.

Yes it can, but in a containerized version under Docker.

There is a Raspbian image with added SSH support available under Hilscher's netPI registry on Docker Hub. This image makes you feel you run netPI like a Pi 3.

First of all it must be said that Docker starts containers with a minimum set of capabilities to grant a maximum of security.

An attack surface is given only if you are not aware of the potential pitfalls due to a risky container configuration, knowingly or unknowingly, at the time the container parameters are set up once in the Docker management UI.

There are different categories how containers and also netPI as Docker host can potentially be compromised:

• threats due to open sockets over Ethernet
• threats due to file system operations
• threats due to shared resources of multiple containers
• threats due to privileged access rights
• threats due to containers from untrusted registries
• threats due to containers performing DoS attacks on others

The Docker daemon is the Docker instance that starts and manages containers. Docker daemon runs under root privileges and thus is by design a risky component to be aware of. If you don't take care an incorrect usage impose a risk of privilege escalation via containers.

Here are major tips to keep Docker containers secured when started on netPI:

1. Only trusted users should be allowed to control your Docker across netPI's Docker management UI. It affords special attention to the processing of netPI's user and role management. Keep your administrator login parameters safe cause protecting elevated authentication credentials is one of the best defense-in-depth strategies you can deploy.
2. Avoid any type of volume mounting. In no way you should mount netPI's host system partition into a container. Else anybody gets direct access to the netPIs operating system without any restrictions and can modify it without regocnition. If there is really necessary to expose a volume keep it in read-only mode. So never do a setup like this showing netPi's system partition / mapped into a container with enabled the option Writeable:
   

    

   
   

    

3. Never enable the option Privileged mode giving access to ALL netPI /dev devices at once within the container. Using this option is nearly as good as if you were root in on netPI's host system. You can mount netPI's boot partition if you want and also the system software partition. So never do a setup like this showing an enables privileged mode:
   

    

   

4. Map as less netPI host devices /dev into a container as possible. Usually there is no need to map host devices AT ALL except you need access to hardware peripherals such as SPI, I2C which can be seen as non risky. 
   So never do a setup like this showing a mapping of the netPI's system partition (even if mount operations on netPI are disabled in a container):
   

    

   

5. Avoid installing packages such as sudo in a container. Even if a user with root rights in a container will never have the same priviledges as one on system level there remains a risk to escalate to the host.
   

    

6. Avoid installing SSH in a container. Containers are made to embed everything to run an application. If there a need for an update usually the whole image of the container is rebuilt and deployed in whole. There is no need usually to log on making modifications online over a SSH connection.
   

    

7. Never map netPI's Docker daemon socket into a container. netPi's Docker daemon listens to a unix domain socket created at /var/run/docker.sock to offer an API for remote control. This interface is used by the way by netPI's Docker management UI to handle the Docker daemon. If you map this path as volume into a container a root user can make use of this API and reconfigure the Docker running on the host. So never do a setup like the following mapping netPI's Docker deamon socket into a container:
   

    

   

Yes absolutely, this is expressly intended.

The CPUs of netPI and Pi 3 are equal. Docker guarantees that containers run the same on platforms of the same architecture. So containers intended to run on netPI finally can be developed and built on a Pi 3 at a reasonable invest of just $30. We feel this is a convenient method to make suitability tests of software on a low-budget hardware first before shifting it onto an industrialized netPI at any later time.

How you install Docker on your Pi 3 under Raspbian OS is described here. It is just a single shell script from the web that installs everything you need in a minute:

curl -sSL https://get.docker.com | sh

When installed a simple test loads a Raspbian OS container onto your Pi and jumps into it (the weird thing is you have now running Raspbian under Raspbian)

docker run -ti resin/rpi-raspbian:latest /bin/bash

entering exit in the container let's you return back to your system Raspbian. All Docker command line (CLI) options such as run are explained here.

Just 8 Steps are needed to containerize your app:

Step 1: Install Docker on your Raspberry

Follow the Raspberry organization instructions: https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/ and just call 

curl -sSL https://get.docker.com | sh

under Raspbian to install Docker.

After the installation you get docker as base command called along with [options] e.g. docker info to interact with Docker and its daemon. A list of the available options can be found here https://docs.docker.com/engine/reference/commandline/docker/#description.

Step 2: Get a base image (OS) for your container

A container needs always a base image your software parts and others can be added to. Base images are available ready to pull on Docker Hub https://hub.docker.com/ already, you don't have to make them yourself.

We recommend to use a Debian(jessie) base image created by group resin.io. Group resin.io is very committed to Raspberry Pi (and others) and offers docker base images for multiple platforms. They are relies and have been pulled over 100K+ times. The choice using Debian(jessie) is because Raspbian OS relies on the same Linux version, so your container will get as similar as possible to Raspbian.

In order to have always the same container behavior in terms of speed, available list of additional sources and compatibility you should pull a fixed version always and not the latest. So call the command

docker pull resin/armv7hf-debian:jessie-20170916

as next to pull a stable version made on 09-16-2017. With no further options a pull command will parse Docker Hub repository automatically to locate the image. Once found (make sure your RPi is connected to the internet) you will see multiple progress bars during the process loading the image layers. It will take up to one minute to pull the base image onto your Raspberry Pi. You will get a confirmation like this at the end:

Digest: sha256:b8fcc10c3227e4aea0d238bbcc8e3e21ac149c56b4628a5fb340b745f5c8679c
Status: Downloaded newer image for resin/armv7hf-debian:jessie-20170916

Use the command

docker images

to list the available docker images on your system and you'll get a result like this

REPOSITORY           TAG             IMAGE ID     CREATED    SIZE
resin/armv7hf-debian jessie-20170916 9b3c27b7a7e4 4 days ago 77.8MB

Step 3: Create a personal container from the image

Use the command

docker create --name myfirstcontainer -it resin/armv7hf-debian:jessie-20170916

to create your first container named myfirstcontainer from the just pulled base image. The option -it is necessary to redirect all containers STDIN outputs to your active shell.

Use the command

docker ps -a

to list all created, stopped and running containers on your system and you'll get a result like this

CONTAINER ID  IMAGE                                COMMAND              CREATED        STATUS    PORTS    NAMES
2747c2137c82  resin/armv7hf-debian:jessie-20170916 "/usr/bin/entry.sh"  12 seconds ago Created            myfirstcontainer

See the status Created. The container is not running yet. Also see the COMMAND column. If not specified otherwise in the command line Docker will use an entrypoint file /usr/bin/entry.sh specified in the base image that will be called at first when the container is started. You may overwrite this file or use the --entrypoint option to specify your own start file.

Step 4: Create your own simple start script

Call the two commands under your Raspbian

echo '#!/bin/bash
/bin/bash' >>entry.sh


and

chmod +x entry.sh

to create an executable file entry.sh that will start just a /bin/bash shell when called.

Step 5: Copy the script file (and others) to the container

Copy the created script file to the container and overwrite the existing one using the command

docker cp entry.sh myfirstcontainer:/usr/bin/entry.sh

By using the same command docker cp construct you are able to copy other files to the container to like docker cp readme.txtmyfirstcontainer:/tmp/readme.txt or some of your application files as well.

Step 6: Start the container

Call

docker start -i myfirstcontainer


The option -i is necessary to attach the containers STDIN to you current shell. Your shell prompt will change from root@raspberrypi:/#(Raspbian) to a prompt like this root@2747c2137c82:/# that signals that you are now running the shell in the context of the container with the ID 2747c2137c82. You are now in the container and execute all your further commands under your base image.

Step 7: Proceed with commands as if you were working under Raspbian

First thing you should do is calling for updates with

apt-get update

Watch the shell output during the update process. It's behaves like on your normal Raspbian.

Continue with your personal installations of tools and executables like

apt-get install wget nano curl build-essential

Finally create, compile or install your application and place it wherever it is needed in the container. Check if it is running as usual in the Container. If not go back to Step 3 and check all available options of the docker create command to give the container more rights.

Also think of editing the entry.sh file to call your application instead of the bash shell.

Step 8: Exit the container and make a portable image of it

Once you are finished with your development call

exit

in the container to leave it and its context.

Now create an image of the container using the command with your persinal credentials

docker commit -m "This is my first container image" -a "John Doe" myfirstcontainer myrepository/myapplication:V1.0.0.0

Call

docker images

to get a fresh list of images on your system. It will list you the following

REPOSITORY                 TAG             IMAGE ID     CREATED       SIZE
resin/armv7hf-debian       jessie-20170916 9b3c27b7a7e4 4 days ago    77.8MB
myrepository/myapplication V1.0.0.0        33fcb9a3560e 5 seconds ago 213MB

Step 8: Push the image to Docker hub to make it visible for netPI

To exchange images across the devices Raspberry and netPI a platform is needed both devices need internet access to. Docker hub is the most popular platform for sharing images publicly or privately. Create an account there before you continue. After that you need to hand over your account credentials username and password to Docker so that it can login also. Use the following command to do this

docker login -u yourusername -p yourpassword

Docker will return a message Login Succeeded when it was able to login successfully.

Now push the created image to Docker hub

docker push myrepository/myapplication:V1.0.0.0

Pretty sure this will fail cause your account is not named myrepository but johndoe for example. Since pushing works only if the local image name matches the account name you can create an image tag reference with the corrected name. You can prevent creating a tag if you commit in Step 7 the target output name like your account docker commit -m "This is my first container image" -a "John Doe" myfirstcontainer johndoe/myapplication:V1.0.0.0. Else use the following command to create a tag

docker tag myrepository/myapplication:V1.0.0.0 johndoe/myapplication:V1.0.0.0

Listing the containers with docker images command gives you

REPOSITORY                 TAG             IMAGE ID     CREATED        SIZE
resin/armv7hf-debian       jessie-20170916 9b3c27b7a7e4 4 days ago     77.8MB
myrepository/myapplication V1.0.0.0        33fcb9a3560e 50 seconds ago 213MB
johndoe/myapplication      V1.0.0.0        33fcb9a3560e 50 seconds ago 213MB

Since the name now equals to your the account name johndoe on Docker hub you can push it now

docker push johndoe/myapplication:V1.0.0.0

Now you are able to pull the image onto netPI and start a container of it.

No, the netPI design includes the netX51 SoC made for Fieldbus or Industrial Ethernet communications as an I/O slave/device/adapter only. This is why netPI cannot be a master or controller of the underlying industrial network.

There are two ways to modify netPI's system software disk partition in whole or in parts. With either method the unit will accept Hilscher signed software packages only. Both methods need manual user intervention to apply. Other automatic methods over the internet for example do not exist because of security reasons.

1. Resetting to factory default: This procedure needs a system software image of type recovery and a USB stick to apply to a netPI. You find the latest system software recovery image in the download section at netiot.com/netPI. The USB stick has to be FAT32 formatted and its volume name be renamed to 'RECOVERY' (all capital letters) to get recognized by netPI as a recovery stick. The provided image comes zipped. Unzip the file and copy the whole content to the root folder of your stick. Plug in the stick into any of netPI's available USB ports and repower netPI. During netPI's boot sequence the stick gets recognized by netPI's bootloader and the recovery procedure starts. netPI indicates the running procedure with the flashing ACT LED. At the end of the procedure ACT LED stops flashing and goes to state "on" for whole second and then goes to state "off" forever. netPI automatically shuts down and wait for a repower cycle.

2. Upgrading software parts: Use netPI's web control panel to apply selective software packages over the menu item "Package Manager". One or multiple packages can be selected, uploaded to netPI and installed one after the other. Those packages are installed with immediate effect not needing any reset.

Because of security reasons on netPI there is no method implemented that allows to recover forgotten web login and passwords.

This is why you should treat your administrator credentials with care and store them safely elsewhere.

The only recovery method is to load netPI with its default software image again going back to the default web login. But in this case all your additional installed software will be lost forerver.