Bosch / SAST / OSSA [Azena] Aims To Be Industry Standard IP Camera OS and App Store

IPVM

We are particularly interested in your comments and questions. There are lots of moving parts and we did not address all of them, for considerations of time and space in the report but we are happy to elaborate or discuss further in the comments.

Reactions:

Undisclosed #1

I predict total and utter failure of this.

Some reasons:

1) Bosch just isn't a big enough force to make this happen. They have not proven themselves as any kind of an innovator in something similar. If Axis was leading this it would at least have a little more clout coming off of their ACAP experience

2) Camera manufacturers are already struggling to differentiate themselves. The last thing they want is a unified OS and app store that makes the hardware itself even more of a "dumb platform".

3) While we may have climbed out of the race to the bottom price trough a bit, margins are still at the point that manufacturers don't want to put the higher-powered CPU's into cameras likely required to fully enables 3rd party apps to do anything worthwhile.

The app store model has worked for companies like Google and Apple that have significant market share, and devices built for that purpose. Other large companies, like Microsoft, have tried and failed to launch their own successful device/app stores. Axis' app store has not been hugely successful, I have hardly ever heard it mentioned by users, or even by Axis employees. This Bosch effort is a tiny fraction of Axis' already not-that-great offering.

Reactions:

(12)

(2)

(3)

(1)

John Honovich

IPVM

Good thoughts.

On pt 2 about differentiation, that is a genuine concern. If all the camera manufacturers have the same fundamental OS and apps, how do they differentiate? Hardware? Price? Not great places for most premium manufacturers to go.

On pt 3, SAST noted the same about higher-powered CPUs, i.e., real cheap cameras using low-end SOCs (e.g., Hisilicon based $30 IP cameras) would not have the processing power to run this. Note: full specs, etc. have not been released on this point.

I was thinking that this could be attractive to some smaller companies that want a more 'trusted' OS / firmware, i.e., "We are Shenzhen small time camera manufacturer but use trusted Germany / American developed firmware"

Reactions:

(2)

(1)

Undisclosed #1

I was thinking that this could be attractive to some smaller companies that want a more 'trusted' OS / firmware, i.e., "We are Shenzhen small time camera manufacturer but use trusted Germany / American developed firmware"

Possibly, though those companies often don't have the sales and marketing presence to ever get elevated above the low-end cost conscious deals. But now they need to add more compute resources, and more than likely encounter some other hidden costs in getting a SAST-camera to market, which then erodes a lot of their advantage.

Additionally, I did not see anything about how SAST will handle or limit any kind of pre-installed app bloat, the garbage you get with most Windows-based PCs these days. You can have a Shenzhen company with a "trusted" OS, but still loads of insecure crap layered on top.

Reactions:

John Honovich

IPVM

I did not see anything about how SAST will handle or limit any kind of pre-installed app bloat, the garbage you get with most Windows-based PCs these days.

In my conversation with SAST's CEO, he did bring up that they are working on removing bloat / unnecessary elements for IP cameras. The details on that, like tech details generally, are not yet released.

Reactions:

(3)

Undisclosed Manufacturer #2

I would think that the limited amount of resources available on the average IP camera would work well to limit bloat, no? There's only so much stuff you can cram onto a camera before it just stops working.

Reactions:

(1)

John Honovich

In reply to Undisclosed Manufacturer #2

IPVM

Expanding on the resource availability issue, that is something that SAST acknowledged is a concern, especially as it relates to running deep learning / AI on the cameras.

SAST says they are working on ways to handle this with those details to be disclosed more fully later.

And this is a problem for IP cameras, including Axis, the relative most successful camera app provider. The computing resources, while relatively high on Axis cameras, are still generally far too low for most deep learning applications to run on the camera. This creates a challenge for camera manufacturers. If they spend more on the SoC / including more computing resources, it will help more people run demanding apps but if those apps are not run on most cameras, the manufacturer has significantly increased the cost / price of those cameras without users taking advantage of the greater potential.

Reactions:

(3)

(1)

Undisclosed Manufacturer #2

Am I wrong in thinking this is why ACAP never really set the industry on fire? I was super gung-ho on the concept when they announced it, but then it kind of... fizzled.

Reactions:

John Honovich

In reply to Undisclosed Manufacturer #2

IPVM

why ACAP never really set the industry on fire?

It's a good question. I am not sure what the most important causes are.

One issue is that Axis did not put its marketing muscle behind it. When Axis wants to push something, they are quite effective in getting the word out. But Axis has never really pushed ACAP hard.

For example, we have literally talked about ACAP nearly as much as Axis, e.g. - Axis Daybreak App Tested, Axis Camera Optimization App (UI Me) Tested, Axis Camera Monitoring App Tested, License Plate Recognition (LPR) Axis App Tested.

The interesting question is why Axis has not pushed apps more. That I am not entirely sure. If you remember Axis Declares Megapixel Race Over! back in 2012, Axis declared:

The race for business and operational intelligence begins. With the ability to download and run applications directly at the edge, the IP camera is now the iPhone of the surveillance world [emphasis added]

Despite this strong claim, Axis never executed the marketing to support that.

Hey, if Bosch gets some momentum on this, I can guarantee Axis will finally put some effort into promoting ACAP...

Reactions:

(2)

(1)

Undisclosed #4

It's a good question. I am not sure what the most important causes are.

I think the answer is fairly simple and mentioned in the article. There is just not a demand for apps on cameras. Dare I say 99%+ of cameras installed just need to record simple video? Building an entire platform around that less than 1% of need seems like a recipe for failure. These won't be $1 apps either and likely will need subscriptions.

That being said I do feel like there needs to be an easier way to search, purchase, download and license the current apps on the market.

Reactions:

(3)

(1)

Undisclosed #1

Dare I say 99%+ of cameras installed just need to record simple video?

And when they don't, the best place for some enhancement software is not always at the edge. ACAP / SAST is not just trying to promote the idea of camera apps, they are also competing with server-side apps ( and Milestone's app partner ecosystem) for the same purpose.

Reactions:

(3)

(1)

(2)

Birger Kollstrand

•Jan 15, 2019

ACAP / SAST is not just trying to promote the idea of camera apps, they are also competing with server-side apps ( and Milestone's app partner ecosystem) for the same purpose.

I disagree. I think this can complement the server side in ways which is hard for us to see today.

Who would have thought that a simple phone could develop into a mobile supercomputer?

Reactions:

(1)

John Honovich

IPVM

Dare I say 99%+ of cameras installed just need to record simple video? Building an entire platform around that less than 1% of need seems like a recipe for failure.

Good point and good concern.

By contrast, most phones have a dozen or dozens of apps installed. For example, Report: Smartphone owners are using 9 apps per day, 30 per month.

I do think that, with an app store, that 99% number will go down and many more cameras will use an app. However, still, how many will use an app? how many apps total? and how big a benefit will it be versus just adding in a few core features to the IP camera itself?

Reactions:

(1)

Undisclosed Manufacturer #9

Agree with John that if this manages to get sufficient traction then the 99% number will drop as accepted thinking changes about what can be done on a camera. Right now there's a number of the (mainly European) security manufacturers looking at how to disrupt the industry, most commonly with approaches / thinking that come from the IT sector rather than the ever lagging security world.

This still needs buyers who are on board - and perhaps this may come from convergence of security with other buying divisions (such as the marketing departments looking to access data from security cameras in retail sector. With constant questions on Security ROI, the marketing department is a new source of funds if they can start to pull other data which gets much easier with edge based analytics of all sorts).

For me, there are some other challenges for this:

- Controlled access to the marketplace - for good or bad, this could encourage end users to try and buy new apps for their edge devices and want to bypass traditional procurement channels. How does a tiered procurement model work? (in particular the role of distribution would be highly questionable, but assume then that integrators own the app store administration for their client sites);

- System configurations and is "All or nothing" needed - is this manageable within mixed networks of legacy and OSSA devices or can this only be effective within an entirely new OSSA system? Is it administered centrally in the network to know and control what devices have which features, and is that done by VMS (eg. is this is effective with a VMS which isn't a member?)

- Load balancing on edge devices - as well as the noted issues around needing to manage the "app store" to avoid malware and unintended consequences, there's also a real issue likely with trying to do too much on any given device, eg. running multiple edge analytics ... who administers and controls the release of apps to the device, and how will they warn the user of potential device overload?

Reactions:

(3)

John Honovich

In reply to Undisclosed Manufacturer #9

IPVM

#9, good questions.

On the controlled access to the marketplace question, response from SAST:

We are planning to set up a dedicated rights management within the Appstore that can control who can download what to which camera. We are currently working with system integrators and end user companies to refine the specifics – e.g. the possibility for a system integrator to “own” the access to cameras that they are responsible for based on their contractual relationship with the end users or end user organizations could set up dedicated people within their organization that are allowed to download apps to their cameras. The goal is to make this flexible yet easy to use àtherefore we are currently gathering feedback to optimize our current thinking and implementation.

On the system configuration question, response from SAST:

The SAST OS will provide standardized interfaces that can be used to integrate into a VMS or other device management solutions. These solutions will not have to be pure play solutions but could be mixed networks. In addition the SAST OS will provide a camera interface (protected by state of the art security mechanisms) that would allow direct access to a particular camera from an authorized user.

Reactions:

Terrence Harless

How many iPhone/Android users pay for their apps. I'm sure there are a few specific apps that are purchased but 95%+ of apps are free due to advertisements within the apps. Don't see that happening to apps on cameras ;).

Reactions:

(1)

Birger Kollstrand

•Jan 15, 2019

why ACAP never really set the industry on fire?

It's a good question. I am not sure what the most important causes are.

One issue is that Axis did not put its marketing muscle behind it. When Axis wants to push something, they are quite effective in getting the word out. But Axis has never really pushed ACAP hard.

The platforms used earlier has not supported this opportunity yet. Looking at the chip-sets that are now available in quite low end phones you see that they are in a different league.

Take out the lcd/oled and battery from a phone you are left with an extremely capable platform and that will show up in cameras if there is a market available for SW.

A bit of chicken and egg, but without standardization it will not happen.

Reactions:

(1)

Craig Lytle

AI/Deep Learning is a particularly difficult example. As silicon vendors add unique features on their chips to accelerate Deep-Neural Networks (DNNs), it is not possible for an 'app' to port efficiently to a specific chip/camera. An AI/Deep Learning algorithm will need to be compiled and optimized specifically for each platform. With DNNs it's no longer the case that just buying a faster CPU will work. There are DNN frameworks that are meant to improve this porting process, but they are not yet up to this vision yet.

Reactions:

(2)

John Honovich

•Oct 06, 2018

IPVM

In reply to Craig Lytle

Craig, good point!

SAST response:

Regarding dnn portability we agree that this is currently at an early stage. We will be working with major SoC vendors to understand how to best support all of their intrinsic HW capabilities while at the same time striving to provide as uniform as possible APIs for APPs that allow to use them without major performance degradation. We expect that this process – whilegoing to take some time – based on for example tensor flow APIs will lead to a better portability for almost all dnn Apps in the next couple of years.

How well (or not) they are able to handle this will be important.

Reactions:

John Collings

MEMOREYES

This should win. Why?

1- Hardware, unless truly unique, is a low margin, volume business. Se la vie.

2- Hardware folks don't like this. So, choose a different playing field.

3- Bosch is a brand. Wants multiple vendors.

4- Without a "IP cam OS" you have... hardware dependency.

5- It will win because in this model, customers win, both sets of customers.

Reactions:

John Honovich

In reply to John Collings

IPVM

1- Hardware, unless truly unique, is a low margin, volume business.

2- Hardware folks don't like this.

Well, most real IP camera manufacturers do not consider themselves hardware providers. The low end, for sure, software is just included as a grudge because it has to be to run. To that end, I could see the attraction for the Shenzhen manufacturers, e.g.

However, I am still struggling to understand why Axis, Avigilon, Hikvision, Hanwha (to name some of the biggest) would ever want to all run the same OS and have the same app store. That would diminish their competitive advantage, no? I am open to be convinced otherwise so let me know.

Reactions:

John Collings

MEMOREYES

"However, I am still struggling to understand why Axis, Avigilon, Hikvision, Hanwha (to name some of the biggest) would ever want to all run the same OS and have the same app store"

They'll never do it. Others will.

And their "software" … only serves them, not the customer. That's where they will lose. Captured entities always escape.

There's only one customer ultimately. The public, the property owner...

An environment of platform operators serves best. IMHO. Pareto Optimum.

That's where this concept serves well. IMHO.

Reactions:

(2)

(1)

Undisclosed Integrator #5

One thing that I am concerned about is how closely this will be monitored. The App Store (iTunes) and Google Play (Android) monitors their app store completely differently. It's very easy to sneak on a virus coded as a "Flashlight" app and have millions of people download it and agree to a Terms and Agreement that let the app send out your personal information. On that note, has Hikvision signed up for this program?

Reactions:

(1)

(5)

John Honovich

In reply to Undisclosed Integrator #5

IPVM

SAST response:

We plan to run malware and other checks on all apps while they are in a staging area and only release them when they passed these checks. Additionally, we plan to insulate apps through the OS so that even if something gets through it can only do limited things based on the rights assigned to it.

Reactions:

(2)

Undisclosed Manufacturer #7

I fully agree with you.

If you look at what Bosch has done in video surveillance, it's a long list of failures, one after another. Their products are not bad at all, but the business strategy is completely wrong. The product quality is not obviously better than Axis or Avigilon, but Bosch tries to keep their margin, by not directly competing with Axis, Avigilon and Hikvision and Dahua for price. When they failed to find their advantages in encoding performance, image quality or even network security, they started to look for fancy new ideas to make each camera to be like a smart phone.

Apparently, Bosch has been misled by smartphone SoC maker who has failed in IoT repeatedly but just does not admit. And it's quite natural that after many failures, Bosch management wanted to make some difference, which is better than none. We have seen similar cases in soccer team coach replacement, the next choice may be not as good as previous one, but you have to make changes and find next coach when the team has failed to find its position in league.

Reactions:

(2)

(1)

John Honovich

In reply to Undisclosed Manufacturer #7

IPVM

If you look at what Bosch has done in video surveillance, it's a long list of failures, one after another.

To me, Bosch's biggest failure is underinvesting. They are consistently a few years behind Axis and Avigilon releasing cameras and have a much narrower portfolio. To be fair, with multi-imagers, they are more like 4 years behind and still have no offering in the now standard, high growth, category.

I think it's good for the industry that they try this moon shot but it would also be good for the industry for them to be serious about keeping pace with Axis and Avigilon.

Reactions:

(1)

Christopher Uiterwyk

IPConfigure

As the first company to build a LPR solution for the Axis ACAP platform this is a great opportunity to standardize the camera platform for software developers. Camera standardization is required for the proliferation of computer vision technologies. We have applied for membership.

Reactions:

(4)

Undisclosed #1

In reply to Christopher Uiterwyk

As the first company to build a LPR solution for the Axis ACAP platform

Serious question, how is that working out for you? Care to share any real numbers of revenue generated, active (not just "downloaded") installations, etc.?

LPR is fairly common application, and Axis is obviously big in the camera space, I would think you would be killing it with a working ACAP LPR app.

Reactions:

Christopher Uiterwyk

IPConfigure

The product was good and well received by the industry. However, IPConfigure's philosophy changed with the launch and success of Orchid VMS. We believe LPR, and analytics in general, are a high expectation (perfection), low volume, high-touch business that becomes a loss leader when priced to sell in volume. Additionally, there are a plethora of variables (positioning, illumination, lensing, resolution, frame-rate, bandwidth, form factor, etc.) that are highly dependent on expert technicians. All of this will get simpler over time with camera hardware and software advancements.

Reactions:

(3)

Undisclosed #10

LPR is not as common as motion detection/tripwire. There is a fair amount of market education required and some tweaking. You can do LPR with any IP camera given the proper lighting and image settings... and of course good algorithms.

One issue is that Axis is behind (i.e. processing power) with their ARTPEC chipset compared to others that you can't effectively do LPR in the camera. That being said, Axis does very little to promote their ACAP partners and competes with them in some cases... what else is new. Any new platform based on standards would be great but I don't believe Bosch would do a better job than Axis in promoting it.

Reactions:

Undisclosed Manufacturer #3

Where I see this as being useful is things like being able to automate or change settings on a schedule or by geolocation. It is a simple cron type job, but not built in to the camera. Even a low powered CPU can do this, or put 1 picture/hour on an ftp server for a time lapse.

The more advanced CPUs then can do the higher level analytics, deep learning, adding core features, etc....

Reactions:

(1)

John Honovich

In reply to Undisclosed Manufacturer #3

IPVM

#3, good point, btw, Axis has apps that do things like that - Axis Daybreak App Tested, Axis Camera Optimization App (UI Me) Tested though since Axis literally has never promoted these two, few know (outside of readers of our tests).

Reactions:

Undisclosed Manufacturer #2

When Ethan wrote that daybreak app post, I emailed it around to a bunch of people, convinced that it was going to change the industry forever.

It did not.

Of course, I tend to get overexcited about things sometimes.

Reactions:

(1)

(4)

(2)

Undisclosed Integrator #5

In reply to Undisclosed Manufacturer #3

Just to add to this, you can set a FTP schedule like you mentioned on the Axis camera too. Without the need of any additional apps or ACAP.

Reactions:

(1)

Undisclosed #4

I am surprised Sony is not part of this being they are tied so tightly to Bosch.

Reactions:

(5)

Undisclosed #1

I think it is just implied at this point. Bosch == Sony == Bosch.

Reactions:

(3)

Undisclosed #4

Lol, somebody needs to tell my Sony rep that.

Reactions:

(1)

(2)

Undisclosed #1

I sometimes envy the Sony reps, they have one of the easiest camera portfolios to manage - it's basically just 2 or 3 models.

Reactions:

(7)

Carl Kristoffersen

I just mighty switch to Sony. :-)

Reactions:

Abdelhamid Metwally

IPVMU Certified

I see that model possibly working quite well for a lot of edge analytics features.

Reactions:

(1)

Undisclosed Integrator #5

I believe the app store and Google Play have a better hold on minimum requirements for app installations. More importantly, most smartphones have more than enough processing power to run the apps that are coming to market (some new AR and fighting games that they show on commercials excluded).

With new cameras coming out, focusing on stream optimization and CPU intensive H.265 streams and multi-streaming, even the current, experienced manufacturer, Axis, doesn't have a lot left over to add processor intensive App's on to the camera. Maybe manufacturer's will use that to promote their own products "Bosch is 99% compatible with our APP Store" but I don't see it taking off.

I don't know why ONVIF didn't try and encompass this in it's scope, but I guess they're having hard enough problems with what's on their plate.

Reactions:

(1)

John Honovich

In reply to Undisclosed Integrator #5

IPVM

I don't know why ONVIF didn't try and encompass this in it's scope, but I guess they're having hard enough problems with what's on their plate.

Good point / question.

For others, first, what ONVIF does with its profiles (S, G, etc.) is fundamentally different than SAST / OSSA. ONVIF Profiles aim for integration / interconnectivity / integration of devices (camera to recorder most commonly). OSSA does not specify / impact that, it deals with a lower level (OS / on-board applications). I would expect OSSA 'conformant' cameras to be simultaneously ONVIF conformant as well.

As for why ONVIF did not do this, my opinion (no inside information) is that (1) Axis would have voted against it (e.g., Axis employees have always been the Chairman of ONVIF) and (2) other steering members who felt this was competitive (e.g., I imagine Hikvision, given their scale would prefer to own their own store) would have opposed as well. Generally, these organizations avoid contention so it made more sense to make a new organization.

Reactions:

(1)

(2)

Sean Nelson

Nelly's Security

A little confused.

Are they proposing to have like a standardized OS (like Android) in which cameras from different manufacturers will all have the same interfaces and user experience but will have different apps to choose from to add specific features and such.

or

Are all the manufacturers going to keep their different types of interfaces/user experiences but simply just choose to join one standardized app store that would just add specific features to their already customized interface?

Reactions:

John Honovich

IPVM

In reply to Sean Nelson

Good question. SAST says they will include a basic web interface that manufacturers can use. However, they expect and we would agree that 'real' manufacturers would redevelop / reinsert their own front-end interface, including various advanced functionalities and options that they use to differentiate.

Reactions:

Sean Nelson

Nelly's Security

meh, i would be more excited if everyone used the same general web interface. I mean if one manufacturer wants to add a bell and whistle here and there to theirs, thats fine. But a standardized web interface would be nice.

Reactions:

(1)

Sean Nelson

Nelly's Security

I can tell you one thing though, if the cheap chinese manufacturers got on board and used the generalized web interface. That would be a good move for them. Alot of decent hardware comes from the smaller manufacturers, but their interface is horrid.

Reactions:

(3)

(1)

Undisclosed Manufacturer #6

I wish them good luck. If they succeed it will boost the progress.

While SAST is about OS and app store, I do not understand what OSSA is about. Based on their site this about "framework outlining a common standardized platform for security and safety devices solutions." Too generic to me. Based on this article ASSA "is effectively the group of companies that will be using SAST software". I probably will also use it, so what?

Can somebody explain?

Reactions:

John Honovich

IPVM

Yes, OSSA's marketing is confusing but it "is effectively the group of companies that will be using SAST software".

From OSSA's home page:

The Open Security & Safety Alliance is a collaboration initiative that brings together like-minded organizations in order to create a framework providing standards and specifications for common components including an operating system, IoT infrastructure, collective approach for data security and privacy [Emphasis Added]

The 'specification' is a specification for SAST, effectively. Their point is that some other software could meet that specification but it seems mostly theoretical since no one else is likely to spend the money to build a rival offering for this 'specification'.

As for membership, the $2,000 annual option gives access to the 'deliverables' and to certify one's products as compliant:

Reactions:

(1)

Undisclosed Manufacturer #8

I can see major potential, but I don't see the industry ready for this yet. The reason app stores on phones sell so much is because you can easily reach a 2 billion person market that can easily buy $1 software. In an office building of 500 people, all 500 of those people have a phone and independently buy apps for their own varying needs. There may be 80 cameras in that building, but only a couple people use or care about them and they typically only have a single purpose.

Reactions:

(3)

Christopher Uiterwyk

In reply to Undisclosed Manufacturer #8

IPConfigure

You have to think about this in the context of distributed computing with the goal of removing heavy iron for storage and CPU intensive solutions. APPs will be primarily agents performing preprocessing, processing, redundant storage, and primary storage functions for both VMS and analytics platforms.

Reactions:

Undisclosed Manufacturer #8

In reply to Christopher Uiterwyk

I get that is the future of IP Video. Decentralized processing and storage can be done now with many manufacturers but few promote the ability. Just like cloud processing/storage and analytics which have been here for a decade and still rarely adopted, decentralization is far far away. I dont see how hardware and software standardization will breed innovation to move us forward. I dont see why developers would spend much time creating flawless content that the hardware manufacturer cant already do for such a small market that historically only cares about a quality image and reliable uptime.

On a seperate note, I hope IPConfigure really takes off with their vision and pushes others to follow.

Reactions:

Christopher Uiterwyk

In reply to Undisclosed Manufacturer #8

IPConfigure

Thanks UM8. The end game is when storage and processing is virtually distributed with redundancy/failover across cameras and simply enabled on OSSA compatible cameras. That being said, an industry sanctioned OS is a risk for western camera manufactures since it could re-level the playing field for China assuming they also adopt the OS. The impact would be similar to how ONVIF removed the need for driver implementations by VMS manufactures which contributed to the success of Chinese camera manufacturers in the West.

Reactions:

(3)

Undisclosed Integrator #11

•Oct 01, 2018

From a integrator's perspective, this is exciting. A standard camera OS and app store opens all sorts of possibilities. For example, a third-party company could develop an app that enabled cameras to use a cloud-based VMS, such as Axis Companion. Or integrators could shop around for a better motion-detection system.

From a former software developer's perspective, this is horrible. A standard OS and app store opens all sorts of security nightmares. App stores have known problems, such as malicious apps. In spite of all efforts to vet apps, there is plenty of malware in the app store that will do Bitcoin mining on your phone, steal your data, etc.

Cryptomining is just the minor annoyance level for something on a camera. What if they installed a backdoor so that somebody with a bit of money to spend could remotely turn off your cameras? Or what if it exported footage (say, once a month and called it an update) to their server for espionage?

So, exciting as it may be, I would much rather stick with software developed by a manufacturer and keep other companies out of it.

Reactions:

(1)

Murat Altu

•Oct 01, 2018

AxxonSoft

I like this initiative! AxxonSoft will support for sure!

VMS should use not only server’s CPU, but also camera’s CPU to provide more efficient system.

And no one mentioned another perspective for all camera manufacturers: free open source OS means credibility.

Once Hik or Dahua supports this OS, no one can blame them that they have some backdoors or any other security issues.

Reactions:

Max V.

Sensorable Systems

ANDROID? I give it a FAIL from the get-go. Here is why ...

1. Android is not an RTOS. It is just not suited for any kind of real time processing.

2. They are building their fort on someone's else land (Google).

3. They will be always behind, playing catch-up with new Android releases and security fixes.

4. Android is UI-centric.

5. Android lacks wired networking support or high throughput networking.

6. Android will require much more storage, RAM, processing power than a microkernel.

7. Google already mooted a new OS to replace Android.

--------------------------------------------------------------------

So they are going to take the latest Android release and strip it down to minimise the overheads. Then, the device manufacturers will have to port their drivers to make it all work together. It's a no easy task demanding highly skilled engineers and rigorous testing. Using an Android clone will cost a lot more.

--------------------------------------------------------------------

Android is a generic OS. Many cameras are made for a specific use case. It makes a lot more sense to have the h/w with a microkernel. That doesn't help interoperability, so my app written for cam A is unlikely to run well, if at all, on cam B.

--------------------------------------------------------------------

Amazon adopted and invested in FreeRTOS for their IoT initiatives. It makes a lot more sense because there is already an established community behind FreeRTOS doing exactly what the OS is supposed to do. In this case Bosch wants to take a UI-centric OS and bring it to a completely different area. Do they expect Android developers to follow?

--------------------------------------------------------------------

There is a big difference between an edge computer with an image sensor and an IP camera running an app. It would totally make sense to have an app store for an edge computer, e.g. Nvidia Jetson or Intel NUC connected to an image sensor (a.k.a. a camera).

--------------------------------------------------------------------

Disclaimer: we use Android for our cams, but they are built on native Android h/w.

Reactions:

(1)

(2)

(1)

Undisclosed Manufacturer #6

In reply to Max V.

Android is not an RTOS. It is just not suited for any kind of real time processing.

Why do you think cameras need real-time OS?

Reactions:

John Collings

MEMOREYES

Ummm… Edge computing?

More importantly, why do you think they don't? … Please, I'm real curious on this.

Reactions:

Undisclosed Manufacturer #6

In reply to John Collings

Ok...Likely RTOS is not what you think it is.
Because it has a narrow purpose.
Because today they do not have RTOS and they are OK.

Reactions:

Max V.

Sensorable Systems

They don't do much edge processing either, so they are OK with a standard *nix microkernel. Frames come in at a predictable rate, IO is buffered and it just rolls on and on. Now add a CNN with a N-layer model wrapped into some poorly optimised app. Oh, hang on, here is an update, we swapped CNN for a CapsNet ...and it all goes haywire.

Reactions:

Max V.

Sensorable Systems

Because real time events won't pause for Android garbage collector to complete.

The frames come at N per second and you don't want to drop any because the system is busy doing something else. Ask your firmware engineers.

Reactions:

(1)

Undisclosed Manufacturer #6

In reply to Max V.

My bad.
I thought they live with no RTOS today.
I thought you have a garbage collector only if you interpreted languages such as Java etc. I did not know it's impossible to use C++ with Android.
I thought non real time OS( like Windows and Linux ) can handle hundreds of cameras on one VMS server handling thousands of fps with no issues.

Reactions:

Undisclosed Manufacturer #6

Max, sorry about my tone. I just a believer you are wrong on this and few other points you originally made. I did not get your arguments. But anyway.. sorry.

Reactions:

Max V.

Sensorable Systems

Man#6, I take your point. Everything is possible if you have enough resources.

If I had to write a C++ app for Linux, I probably wouldn't want the overhead of Android.

Reactions:

John Collings

MEMOREYES

In reply to Max V.

Hi Max - I like your brass. But, remember Moore's law, and 5G, and edge events that are certainly coming.

That said. … What do you propose?

Reactions:

John Poole

The link in the first sentence of the first paragraph of this article just goes to an image file:

spinout SAST will become

Is the link to SAST suppose to be to an image file?

Reactions:

Dan Gelinas

IPVM

In reply to John Poole

Thank you for catching that. We've now linked to the SAST group's website.

Reactions:

John Poole

SAST states:

Camera OS

We’ve created an operating system to serve as the industry standard for security cameras. Based on the Android Open Source Project (AOSP), it gives developers libraries, an API framework, and codecs to work with.

Hmmm... after seeing unparalleled success of Linux, an open source operating system, you would think the camera industry would understand the premise that open source is a viable solution and here to stay. Especially with the concern about backdoors. A group of manufacturers collaborating to create an operating system that may be closed source seems short-sighted. Perhaps I am misconstruing what the nature of their proposed operating system will be? The fact that the phrase "open source" only appears once on the page at https://www.sast.io/our-platform entitled "Our Platform" and in reference to Android causes me to conclude that the proposed operating system will be closed source. If that is the case, then I think this will be a problem.

Reactions:

Undisclosed Integrator #12

•Oct 05, 2018

Hi All. The principle seems sound but like others my major concerns would be around security and the ability for anyone with the required rights to download a bit of software onto a previously signed off / working system. Regardless of any reassurances, someone will eventually introduce some malware via this route and it will be the maintainers responsibility to sort it out.

Thanks

Reactions:

John Honovich

•Oct 06, 2018

IPVM

Voting results reviewed:

Overall, modest interest in an IP camera app store, though manufacturers are notably more bullish than integrators (e.g. 43% of manufacturers vs just 33% of integrators).

Reactions:

(1)

Undisclosed #13

A very interesting idea.
1. Does anyone have information on how quickly is this plan of Bosch going to happen?
2. Any information on how common is Android in IP cameras? So far I was under the assumption that that Android is uncommon, and mostly for the consumer market.

Reactions:

(1)

John Honovich

In reply to Undisclosed #13

IPVM

#13, thanks for your first comment.

1. Bosch and other members of the 'Alliance' are planning to release first camera models in 2019, though we expect them to be limited models, i.e., they are not going to change over all their existing models immediately.

2. I have not seen any IP camera manufacturer market being Android, so there may be some, it has to be a very small minority.

Reactions:

(1)

Undisclosed #14