Find place for your discussion in the netPI Forums
|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|
|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)|
|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|
|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|
|Yocto project based customized Linux, Kernel 4.9.x or higher|
|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|
|Obligatory password authentication with key strength calculator|
|User and role management prohibiting unauthorized access to preinstalled software|
|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.
With Raspberry the focus is "the affordable PC for everybody"
an open and customizable software ecosystem like Raspbian OS. The brilliant
concept at platform's best price/performance ratio is encouraging the community to
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
software 1.) is a chaotic mix of multiple components embedding unpredictable
risks and 2.) has never been assessed and designed concerning security at
netPI however is different and its security concept was considered from the beginning. Docker plays a significant role in this concept.
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.
There are two possibilities dealing with container images.
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.
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.
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.
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 interface||NIOT-E-NPIX-RS232|
|RS485 serial interface||NIOT-E-NPIX-RS485|
|4 Digital Input/Output||NIOT-E-NPIX-4DI4DO|
|NPIX slot evaluation board||NIOT-E-NPIX-EVA|
|Main Processor||Broadcom BCM2837, |
64Bit quad-core @1.2Ghz
|RAM Memory||1 GByte|
|FRAM Memory||8 KByte (RTE 3 only)|
|FLASH Memory||8 GByte, MLC NAND (384TBW)|
32 GByte, pSLC NAND (1920TBW)
|Interfaces||4 x USB 2.0A (max. load 1A), |
1 x HDMI, 1 x Wifi/BT
|Real-time clock||supercapacitor buffered |
(7 days backup)
|Industrial Network SoC||netX 51 (RTE 3 only)|
|Ethernet||1 x RJ45 standard, 10/100Mbit/s|
2 x RJ45 industrial, 10/100Mbit/s (RTE 3 only)
|Indicators||8 LEDs, 2 programmable (RTE 3)|
4 LEDs, 2 programmable (CORE 3)
|Dimensions||140 x 35 x 105 mm (H x W x L)|
|Enclosure||Metallic, top hat rail-mountable, IP 20|
|Power Consumption||min. 4,2W (no USB), |
max. 9W (USBs max. load 1A)
|Temperatures||-20°C ... +60°C operating,|
-40°C ... +85°C storage
|Approvals||CE, FCC, UL, KCC, RED|
|EMC||EN 55011:2009, IEC 61000-6-2/3:2005, |
|Shock and Vibration||IEC 60068-2-27:2008-02,|
|Operating System||Yocto based Linux, Kernel 4.9.x or higher|
|Docker||18.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.
netPI example containers can be found at Docker Hub
Source codes of netPI example containers can be found at GitHub
Get in touch with the netPI Team in the official forums
Find netPI screen casts on YouTube
|netPI - Datasheet ENGLISH||netPI_Datasheet_01-2021_GB.pdf|
|netPI - Datasheet GERMAN||netPI_Datenblatt_01-2021_DE.pdf|
|netPI RTE - User Manual ENGLISH||Rev. 4||netPI RTE NIOT-E-NPI3-51-EN-RE UM 04 EN.pdf|
|netPI RTE - User Manual GERMAN||Rev. 4||netPI RTE NIOT-E-NPI3-51-EN-RE UM 04 DE.pdf|
|netPI CORE - User Manual ENGLISH||Rev. 4||netPI CORE NIOT-E-NPI3-EN UM 04 EN.pdf|
|netPI CORE - User Manual GERMAN||Rev. 4||netPI 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 ENGLISH||Rev. 7||NPIX_Extension_Modules_HW_07_EN.pdf|
|NPIX - User Manual GERMAN||Rev. 7||NPIX_Erweiterungsmodule_HW_07_DE.pdf|
|System Software: |
|V188.8.131.52||System software package for netPI RTE 3 and CORE 3|
|3D CAD model netPI||-||netPI Housing as .step file (zipped)|
At the netIOT Shop you can order your netPI and accessories - globally
For larger quantities,
netPI directly from Hilscher.
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.
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.
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.
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:
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:
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:
/mapped into a container with enabled the option
Privileged modegiving access to ALL netPI
/devdevices 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:
/devinto 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.
sudoin 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.
/var/run/docker.sockto 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
exit in the
container let's you return back to your system Raspbian. All Docker command
line (CLI) options such as
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 |
under Raspbian to install Docker.
After the installation you get
base command called along with
docker info to interact
with Docker and its daemon. A list of the available options can be found
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
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:
Status: Downloaded newer image for resin/armv7hf-debian:jessie-20170916
Use the command
to list the available docker images on your system and you'll get a result like this
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
--name myfirstcontainer -it
to create your first container named
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
2747c2137c82 resin/armv7hf-debian:jessie-20170916 "/usr/bin/entry.sh" 12 seconds ago Created myfirstcontainer
See the status
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
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
to create an executable file
will start just a
/bin/bash shell when
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
By using the same command
cp construct you are able to copy other files to the container
docker cp or
some of your application files as well.
Step 6: Start the container
docker start -i
necessary to attach the containers STDIN to you current shell. Your shell
prompt will change from
to a prompt like this
that signals that you are now running the shell in the context of the
container with the ID
are now in the container and execute all your further commands under your
Step 7: Proceed with commands as if you were working under Raspbian
First thing you should do is calling for updates with
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
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
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
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
to get a fresh list of images on your system. It will list you the
IMAGE ID CREATED
resin/armv7hf-debian jessie-20170916 9b3c27b7a7e4 4 days ago 77.8MB
myrepository/myapplication V184.108.40.206 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
Docker will return a message
Succeeded when it was able to login successfully.
Now push the created image to Docker hub
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
commit -m "This is my first container image" -a "John Doe"
myfirstcontainer johndoe/myapplication:V220.127.116.11. Else use the
following command to create a tag
Listing the containers with
images command gives you
IMAGE ID CREATED
resin/armv7hf-debian jessie-20170916 9b3c27b7a7e4 4 days ago 77.8MB
myrepository/myapplication V18.104.22.168 33fcb9a3560e 50 seconds ago 213MB
johndoe/myapplication V22.214.171.124 33fcb9a3560e 50 seconds ago 213MB
Since the name now equals to your the account name johndoe on Docker hub you can push it now
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.