In conjunction with Smart Devices the so called Apps enter the world of Embedded Devices and Industrial Controllers. This may lead to enormous costs for new development tools and sales channels which these kind of cloud and app developments bring along. Using rApp, manufacturers or users of such devices get a platform which eliminates the need to provide apps that run on Smart Devices. Instead it enables them to provide their apps together with their devices - in a way "remote" from the smart device.
Smart Devices for controlling, engineering, diagnosis and configuration of industrial controllers, automation systems as well as home appliances have become very popular and are a demanding request for manufacturors of these devices. Thus, these manufactureres face new challenges: besides there device software they will have to provide apps for smart devices as well. These apps will have to communicate with their devices either directly/locally or via the Internet. Furthermore, new sales channels will be faced, the so called App Stores. Finally, the device software as well as their corresponding apps will have to work together when being used by the end customer. To solve these new challenges, two different approaches are currently used, both having their specific advantages and disadvantages.
fat clients and thin clients - pros and cons
Using the fat client principle, the device manufacturer provides interfaces for the smart devices within his devices. The apps running on the smart devices are created specifically for the corresponding devices and directly run on the smart device. Thus they are called "native apps". For different smart devices on the market there are different, incompatible operating systems (Apple iOS, Android, Windows Phone, ...) as well. Furthermore, there is a big variety of different screen sizes. For all these variants the device manufacturer will have to provide the appropriate apps. Finally, these apps have to be provided by the different stores of the smart device manufacturers where also different regulation exist - regulations that cannot be negotiated. The app may even be completely rejected by the app store provider.
Additional disadvantages are the fast innovation cycle of smart device operating systems as well the hardware of these devices which leads to a steady effort in maintaining the apps even years after they have been released.
Finally the device manufacturer has to assure that the software running on his embedded device as well as the app running on the smart device are compatible to each other. New apps may have to support both, new and old versions of the software running on the embedded device - and vice versa for the software running on the embedded device. This will be hard to manage as typically there exists a big variety of embedded devices with different software versions and the corresponding apps are provided in a different sales channel. Both pieces typically are on the market for many years and finally an confusing number of combination of software versions will end in frustration.
Of course there are advantages using native apps: there is no restriction in accessing sensors and actors of smart devices, e. g. camera, buttons and services like email, Internet gateway or receiving push messages. Also native look & feel and high responsivness and performance can be achieved. As the CPU power of smart devices is continuously increasing the performance aspect will lose its significance.
Anyway, the thin client principle has its own specific drawbacks: There is only limited access of the smart device's hardware sensors and actors from within the web client. In addition there are compatibility issues within different versions of the various web clients even on the same type of smart device. Another drawback is the need of a webserver within the manufacturer's embedded device. Besides resource and maintainance aspects there may be patent issues as well.
fat clients and thin clients - security
In both cases, which also can be mixed (so called hybrid apps), the active role always is on the client side: the smart device. The manufacturer's embedded devices are in the passive (server) role and wait, using an inbound IP port, until a smart device starts connecting. Due to this passive role the manufacturer's devices may become a vulnerable target for outside security attacks which finally can lead to a device or even general IT security issue. Once the security fence has been broken down the attacker may completely take over the embedded device and misuse it. Very often device manufacturers use open source web servers or IP stacks where security mechanisms and issues are well known by potential attackers.