Industrial Raspberry Pi 3 as Open Edge Connectivity Ecosystem

netPI - build, ship, run secure on the Edge!

netPI RTE 3, netPI CORE 3, and NPIX

Industrial Raspberry Pi as Open Edge Connectivity Ecosystem

  • Multi-protocol Industrial Ethernet support
  • Web GUI maintained Docker ecosystem
  • -20 - 60°C, full CPU speed till 50 °C ambient air
  • Replaceable 8 or 32 GB industrial micro SD card
  • Expandable with additional networking modules
  • CE, FCC, UL, KCC, RED certified, MTBF available

Find place for your discussion in the netPI Forums

netPI is a Raspberry Pi 3 B architecture based platform for implementing Cloud, Internet of Things and Industry 4.0 customized Edge Automation projects safely over containerized software utilizing Docker. Hilscher designed it in cooperation with Element14, the Raspberry manufacturer, and upgraded it specially for industrial use. Its single-circuit board combines the Pi 3 B circuitry, its standard interfaces, Hilscher's multi-protocol Industrial Network SoC netX plus two extra Industrial Ethernet ports. By design netPI's overall software architecture complies with the Cyber Security Standard IEC 62443 for Industrial Automation and Control Systems to counter threats such as unauthorized accesses, software manipulation and eavesdropping and relies on a security enhanced Linux. Default access for configuring and managing it is granted via a web-based GUI. Additional software and applications can only be applied by accredited users using the preinstalled Docker virtualization environment in isolated and safe containers to be inline with the security concept.

Industrial graded

netPI features hardware upgrades that vastly improve the platform for industrial use.
Design
8 layer PCB design (6 with Pi 3 B) for best EMC compliance and heat dissipation
Cooling concept for full 1.2GHz quad-core CPU performance up to 50°C without throttling
Peripherals
8GB (384TBW) / 32GB (1920TBW) industrial grade long-life FLASH memory with guaranteed constant BOM
Real-Time Clock (RTC) with 7 days maintenance-free supercapacitor based buffering
8KB extra FRAM for storing data non-volatile at high frequencies (model RTE 3)
Connectivity
netX51 multi-protocol Industrial Networks Controller for Fieldbus and Industrial Ethernet (model RTE 3)
Two extra Industrial Ethernet ports for protocols such as PROFINET, EtherNet/IP, EtherCAT, POWERLINK, Modbus/TCP and more (model RTE 3)
Expansion slot for additional plug-in modules such as RS485, RFID, Analog, Digital I/O and more
DIN rail mountable robust metallic housing for longevity in industrial environments
Environments
On-board WiFi/BT radio antenna extended beyond chassis for best wireless coverage
EMC compliant to latest standards
Shock and vibration compliant to latest standards
Extended temperature range -20°C to 60°C
24 Volt DC powering

Secured infrastructure

netPI features default system security to countermeasure today's cyber threats.
Design
Yocto project based customized Linux, Kernel 4.9.x or higher
Integrity
Constraint checking of the validity of the booted software through keys
Coordinated installation of system updates and patches through signed packages only
Ignoring removable media such as USB sticks prohibiting infiltration of malware
Authentication
Obligatory password authentication with key strength calculator
User and role management prohibiting unauthorized access to preinstalled software
Confidentiality
Protection of the transmission route to the web GUI by TLS 1.2 encryption (https)
NGINX application as reverse proxy for centralized SSL certificates offloading and handling
Non-installed SSH server to prohibit accesses from remote through a console
Non-installed sudo command to prevent getting root privileges
Restricted Data Flow
AppArmor security framework restricted preinstalled components through access profiles
Physical segregation of IT and OT networks by two separated network controllers (model RTE 3)
Preinstalled Docker for additional container-isolated applications over web GUI client portainer.io

netPI is a Docker host. Docker is a software that packs applications into containers and runs them as they would run on system-level but isolated in their private virtual environments. Any container is launched from a specific image template that is a software snapshot of everything the container needs to run autonomously such as operating system, directories, tools, applications, user-added files and configuration settings. When a container is created Docker virtualizes an instance of the self-contained image and adds dynamic aspects to it like an own drive volume, network stack, namespaces and control groups. This form of isolation allows to run multiple containers at a time without influencing each other or the Docker host. Image templates are portable and can be exchanged across registries. This enables distributing and shipping ones work to everybody either in privat or public manner. For easy on-board Docker management netPI provides the Docker web UI portainer.io as front end to the user.


Security by Design

With Raspberry the focus is "the affordable PC for everybody" with an open and customizable software ecosystem like Raspbian OS. The brilliant playground concept at platform's best price/performance ratio is encouraging the community to the day realizing even the most unusual computer projects with it. But openness embeds drawbacks. When applications are directed to the industry security is coming significantly to the fore. In the majority of today's Raspberry projects the provided software 1.) is a chaotic mix of multiple components embedding unpredictable security risks and 2.) has never been assessed and designed concerning security at all.

netPI however is different and its security concept was considered from the beginning. Docker plays a significant role in this concept.


In accordance with IEC 62443

Docker starts containers with a white list restricted set of capabilities to make the Docker host system immune to external exposures by default. But Docker is running as root and could pass this privilege and others on to a container. However the simple example of a containerized web server application binding just a specific port on providing its web content makes clear that in nearly 100% of all cases giving privileges is not needed at all. Security comes first here. Even if the web server is perfectly operating, an intruder would never succeed to become system root independent how vulnerable it is if the container is of type non-root. So with Docker security is just a matter of provided container privileges. The IEC 62443 claims to live a consequent asset life-cycle security and risk management in an administered way. It prescribes that only suitably trained and accredited personnel are entitled to manage as critically identified components such as Docker. So netPI's security rises and falls with the administrators responsible for its setup.


Containerized Software

There are two possibilities dealing with container images. Either you use already built images with ready-made applications or you build own images fitting your demands.

Building an own image is easy. An image needs a base and in best case it consists just of that. The base consist usually of an operating system like Ubuntu, Debian or CentOS. Those and many more are offered prebuilt on Docker's public registry Docker Hub ready for pulling. Naturally the well-known Raspbian is provided too. On top of this image you can add and install everything your application shall consist of. When ready you make the final commit of your customized image. You can keep it private or upload it to the registry for others.


Raspberry as Development Platform

netPI is a Docker host only. You can deploy images and run containers from them but you cannot build images on-board. netPI's security concept prohibits SSH servicing and hence you can't get access to Docker build commands. Since containers run the same on any compatible hardware use a Raspberry Pi 3 instead for image development. We feel $30 for the consumer Pi is a low and riskless invest for getting familiar with Docker, making usability and performance tests of applications before moving them onto the professional netPI. Try it out today and install Docker with a single command on your Pi as described here.

Node-RED is today's best web browser-based toolsuite for developing Cloud, Internet of Things and Industry 4.0 projects in an intuitive way. "Clicking" together logical data relations of heterogeneous services by leveraging pre-built blocks of code named "Nodes" in a flow-based manner is achieving such a high abstraction degree that even amateurs quickly understand its principle and can develop impressive data flows rapidly. In seconds data from one source such as TCP/IP, HTTP, MQTT, Email, serial etc. can be brought into a context and linked together with data from any other sources to a destination by simple mouse clicks. The Raspberry organization recognized the simplicity of Node-RED as well and made it an integral part of their Raspbian (desktop version). Renowned manufacturers such as IBM, Microsoft and Amazon discovered it for their own use and offer nodes establishing communication links to their Cloud solutions free to download. The community counts over 1000 nodes meanwhile which underlines the power of Node-RED. Its widespread use, its JavaScript programing language basis, its ease of use, the very minimal to no coding were reasons for us to offer netPI's features in samples of Node-RED nodes inclusive their source code.


Industrial Networking

The netPI RTE 3 device features a multi-protocol controller netX supporting the most common Industrial Ethernet or Fieldbus protocols as a slave/device. A simple input and output memory buffer exchanges IO data between a bus master and an application program transparently. Switching between different protocols is just a thing of loading and starting the chip with a different firmware. For immediate use a reference implemenation of the protocols PROFINET IO device and EtherNet/IP adapter are available as Fieldbus nodes for Node-RED with a link to the source code. C code based running examples for the protocols PROFINET, EtherCAT, EtherNet/IP, Modbus TCP and POWERLINK are made public as well for supporting programmers dealing with own applications.


FRAM for non-volatile data storage

netPI RTE 3 features an FRAM (NVRAM) to store frequently changing data non-volatile where a normal NAND FLASH comes to its limits. A sample container with two FRAM nodes written for Node-RED in Javascript are providing random read and write access to this memory. With the linked container's source code programmers have an easy life in abstracting the FRAM access logic and transforming it to another programming language.


Expansion modules

For maximum connectivity netPI features an expansion slot at its bottom where different networking modules named NPIX (NetPIeXpansion) can be applied to. Sample containers with a Node-RED implementation mostly in focus enable their immediate use. The source code is always linked and serves as programming reference for other programming scenarios. The NPIX board/slot dimensions and connector pinout are public for everybody allowing the development of own designs with our help. Today's available modules are:

RS232 serial interfaceNIOT-E-NPIX-RS232
RS485 serial interfaceNIOT-E-NPIX-RS485
CAN 2.0A/BNIOT-E-NPIX-RCAN
4 Digital Input/OutputNIOT-E-NPIX-4DI4DO
NPIX slot evaluation boardNIOT-E-NPIX-EVA

Main ProcessorBroadcom BCM2837,
64Bit quad-core @1.2Ghz
RAM Memory1 GByte
FRAM Memory8 KByte (RTE 3 only)
FLASH Memory8 GByte, MLC NAND (384TBW)
32 GByte, pSLC NAND (1920TBW)
Interfaces4 x USB 2.0A (max. load 1A),
1 x HDMI, 1 x Wifi/BT
Real-time clocksupercapacitor buffered
(7 days backup)
Industrial Network SoCnetX 51 (RTE 3 only)

Ethernet1 x RJ45 standard, 10/100Mbit/s
2 x RJ45 industrial, 10/100Mbit/s (RTE 3 only)
Indicators8 LEDs, 2 programmable (RTE 3)
4 LEDs, 2 programmable (CORE 3)
Dimensions 140 x 35 x 105 mm (H x W x L)

EnclosureMetallic, top hat rail-mountable, IP 20
Weight400g
Power Consumptionmin. 4,2W (no USB),
max. 9W (USBs max. load 1A)
Temperatures-20°C ... +60°C operating,
-40°C ... +85°C storage
ApprovalsCE, FCC, UL, KCC, RED
EMCEN 55011:2009, IEC 61000-6-2/3:2005,
EN 61131-2
Shock and VibrationIEC 60068-2-27:2008-02,
IEC 60068-2-6:2007-12

Operating SystemYocto based Linux, Kernel 4.9.x or higher
(AppArmor secured)
Docker18.09.2-ce or higher with portainer.io web UI

Need help with netPI development? Find below the resources needed for starting your own projects.

Card image cap
Docker Hub

netPI example containers can be found at Docker Hub

Docker Hub
Card image cap
GitHub

Source codes of netPI example containers can be found at GitHub

GitHub
Card image cap
Forum

Get in touch with the netPI Team in the official forums

Forum
Card image cap
Video Tutorials

Find netPI screen casts on YouTube

YouTube
TypeVersionChanges/ContentDownload
netPI - Datasheet ENGLISH netPI_Datasheet_01-2021_GB.pdf
netPI - Datasheet GERMAN netPI_Datenblatt_01-2021_DE.pdf
netPI RTE - User Manual ENGLISHRev. 4netPI RTE NIOT-E-NPI3-51-EN-RE UM 04 EN.pdf
netPI RTE - User Manual GERMANRev. 4netPI RTE NIOT-E-NPI3-51-EN-RE UM 04 DE.pdf
netPI CORE - User Manual ENGLISHRev. 4netPI CORE NIOT-E-NPI3-EN UM 04 EN.pdf
netPI CORE - User Manual GERMANRev. 4netPI CORE NIOT-E-NPI3-EN UM 04 DE.pdf
netPI RTE - EU - Declaration of Conformity-1321.500_NIOT-E-NPI3-51-EN-RE_EN.pdf
netPI CORE - EU - Declaration of Conformity-1321.438_NIOT-E-NPI3-EN_EN.pdf
NPIX - User Manual ENGLISHRev. 7NPIX_Extension_Modules_HW_07_EN.pdf
NPIX - User Manual GERMANRev. 7NPIX_Erweiterungsmodule_HW_07_DE.pdf
System Software:
Recovery image
V1.2.2.0System software package for netPI RTE 3 and CORE 3
3D CAD model netPI-netPI Housing as .step file (zipped)

All netPI models can be purchased via the netIOT Shop (shipps globally). If you want to order larger volumes, feel free to contact us

Card image cap
netIOT Shop

At the netIOT Shop you can order your netPI and accessories - globally

To the netIOT Shop
Card image cap
Hilscher

For larger quantities, purchase netPI directly from Hilscher.

To Hilscher.com
What is netPI?

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.

How compatible is netPI with a Raspberry Pi 3?

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.

Which Software is running on netPI?

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.

How can I access netPI?

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.

Are there Docker examples?

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.

Does netPI software run slower if it is running "dockerized" in containers?

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.

I am used to Raspbian OS, can it run on netPI too?

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.

What are the security concerns using Docker and apps in containers?

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:

     

Can I develop a container on a Raspberry Pi and deploy it later on a netPI?

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.

How can I containerize an existing application on my Raspberry Pi?

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.

Is netPI able to be a controller/master on the industrial network?

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.

How can software be updated on netPI?

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.

How can I recover forgotten web logins and passwords?

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.