You are not alone
There’s a reason these questions are frequently asked.
In case we haven’t been clear, this is the FAQ.
Sometimes potential clients have some extremely specific questions about what we do and how we can do it for them. But often, the first round of questions we get tend to be fairly similar to those we’ve been asked before. You might even say, frequently. So here they are. But the one thing you’ll have to answer for yourself is whether it’s pronounced “ef-ay-cue,” “fack,” or “fă-cue.”
Company
Does ObjectSpectrum offer a “white label” option?
Yes, and really everything we do is a white labeled solution. We aren’t in the business of selling an end-user product. Our logo doesn’t go on your solution. Everything about the look and feel, theme, styling, etc is going to be your identity – built to your specifications.
How long has ObjectSpectrum been developing IoT solutions?
Since April of 2016.
What industries or vertical markets does ObjectSpectrum have experience with?
These are some of the more common industries that we work with. But just because it isn’t listed there doesn’t mean we wouldn’t or couldn’t do it. We work with IoT, not a specific industry. If you need IoT and you’re in a different industry than you see here, you need us. Because you need IoT.
What services does ObjectSpectrum provide?
Consulting, Design (product, software, firmware, application, UI/UX), Development (software, firmware), Application Management (hosting your IoT solution, the ongoing management of it, supporting software services). To that last point, when we host someone’s IoT application, it’s not like we have one server hosting that IoT application. It runs across many different servers and uses many other servers that provide services (like everything from email to text messaging, to message brokering to database, etc.) so it’s a big environment that has dozens of servers that are all there to support your application. We also provide something we call IoT as a Service, which is a full turn-key outsourcing of the ongoing operations of an IoT deployment, providing as much or as little of the ongoing operations as you like.
What kind of companies are typical of ObjectSpectrum customers?
The bulk of our customers are Original Equipment Manufacturer (OEM) companies that are 1) looking to bring a new product/service to the market or 2) want to add IoT capabilities to an existing product or service that they already offer. These are typically mid-size and larger companies, and sometimes “well-funded” start-ups.
A secondary category making up a smaller portion of our customers are enterprise companies that are big enough to justify the cost of custom-developed solutions for their own us.
Check out this page to see if you fit into the types of customers we usually work with.
Where is ObjectSpectrum based?
We are based in Frisco, TX which is a suburb of Dallas.
Has ObjectSpectrum won any industry awards?
Yup. You can see what we’ve won here if you’d like.
Does ObjectSpectrum comply with industry regulations for medical applications (like HIPAA)?
Yes. And for our customers that are bound by HIPAA, we regularly sign a Business Associate Agreement (BAA).
When ObjectSpectrum develops an IoT solution, who owns it?
You do. When we build it, we will use both third-party software and our own software (Prism) as part of building the solution. Those third-party pieces might be open-source, or they might be commercially licensed (and of course we’ll let you know what tools we’re using), but the application that ObjectSpectrum builds to your specs belongs to you, the customer.
Who owns the data that is collected or derived from my IoT solution?
You, the customer, do.
Does ObjectSpectrum offer support?
Nope, you’re on your own, sucka. Okay, okay – yes, of course we do. As part of us hosting your solution for you, support for you is included within that service contract. If you are licensing our software, support is also provided as part of that licensing contract. And while those options don’t include support to your end customers, end customer support is one of the optional services you can choose (as part of our IoT as a Service offering).
Why use ObjectSpectrum instead of an IoT SaaS company?
ObjectSpectrum is primarily a software engineering company, focused on creating IoT solutions. We are more like a traditional software outsourcing company than a SaaS provider. An IoT SaaS company is primarily looking for a customer that wants to do it themselves and is willing to operate within the constraints of their software. The closer you get to a tool that can be used by non-software engineers (i.e. application designers and developers), the more you will have to play by the rules they have created in their software. Their software will let you take your knowledge of your warehouse, for example, and combine that with their software to connect and monitor this thing and that thing, and that’s great. But by targeting that kind of a user, you are going to be putting constraints around what you can do. And for some people, this may be completely fine. That might be the best choice for them and their situation.
If you are an enterprise customer, and what you need is to collect data from a hundred different sensors in your factory, or GPS trackers on your hundred different pieces of heavy equipment, then an IoT SaaS company could be okay for you because it will let you build a functional application. But the problem is that you are still going to be working within those constraints. To be clear, we are not knocking the idea of you working with an IoT SaaS company. We are just stating what’s different about that type of company and ObjectSpectrum. It’s important for you to understand the differences so that you can make the best choice for your specific situation.
But the dirty little secret of any SaaS company is that if you need to go beyond the scope of capability that they deliver to you, you either a) have no choice because they didn’t provide you with a way to extend it, or b) you now need to bring in the hardcore developers that are necessary to go beyond that set of functionality provided with the software. If you’re trying to build an application that is going to be offered for sale, either as a standalone service or as part of something that you’re selling, you want something that is a lot closer to from-scratch software development. You want something that doesn’t have those constraints; you need something that isn’t designed for a non-technical user. Because you’re going to run into issues with the SaaS products where they simply don’t meet your needs, and then what do you do? So the target audience for this is typically someone who is using it internally and they’ll tell you, “oh no, you can white label it, put your logo on it and offer it to your customers,” and that’s all great. If what you actually need is what they thought you needed, you’re in good shape. But as soon as you cross that line, you’re now into having to bring in the technical people to actually get the job done.
The bottom line is that an IoT SaaS company is not in the business of IoT solutions engineering. It is in the business of licensing a piece of software. ObjectSpectrum is in the business of solutions engineering. Tools like an IoT SaaS company can be a great prototyping tool. Because once you learn how to use their tool, it can be very quick and easy to set up, “okay, we need to monitor these five sensors and we need to test this thing over the next two weeks” and that type of stuff. It can be a great prototyping tool. Unfortunately, with most IoT SaaS companies, it comes with a pretty high price tag just to license it. So that makes it kind of an expensive prototyping tool. That’s not the case for every single one of them (IoT SaaS companies), but it is with a lot of them.
Why use ObjectSpectrum instead of a custom software or an Internet application development firm?
There are three issues here:
- ObjectSpectrum has our own software and tools that were purpose-built to rapidly design, develop and deploy IoT solutions. That is our secret (or not so secret, since we’re putting it on a public website) weapon. If you go to a software outsourcing firm, they are going to use tools, development environments and third-party components and whatnot that they know and that are available to them in the market. They’re not bringing any intellectual property of their own to the table. We’re bringing intellectual property that was purpose-built to accelerate these types of solutions and not only for the purpose of making it go faster, which directly translates into less cost, but also in reducing risk. In the sense that, when we develop a solution, we are using a set of tools and libraries and both in-house developed and third-party stuff that already works together and has already been field-proven and tested. We already know that it’s secure. We already know that it scales. We already know all of this stuff about it, whereas a custom developer has to figure that out about every single aspect of even the tiniest components they create as a part of the solution. In a sense, nobody starts from scratch these days – ‘cause what does “from scratch” mean anyway? But the difference is that we’re starting you five years ahead of where you would be starting without us. Way ahead. Our starting point is 80% of the finish line compared to the 0% starting point of any software outsourcing firm would be starting from.
- They may not have a lot of experience in IoT. Maybe they’ve developed complex games, or maybe they’ve developed complex e-commerce websites. However, the skillset to create applications like those are not the same skillset required to create IoT applications. There can be some overlap, but not necessarily. Do not be fooled by promises made by sales engineers who say, “We can do this, we can do that, we can do IoT.” IoT is very different. It’s a very deep “stack” with many layers – much more so than an e-commerce site. But even if you don’t want to compare them, you can just say that they’re very different. We wouldn’t use Prism (our IoT solution platform) to write a first-person shooter game, for example. And it’s also about expertise. We are specifically and solely focused on IoT, we have deep experience at all levels of the stack, we have strong relationships in the ecosystem (vastly undervalued by some), and we know what it takes to design, develop, and deploy an IoT solution having focused on solely those since 2016.
- Unlike typical custom software development firms, we become our customer’s software partner. That’s a lot of talk in many cases, but for us, it means that we host the application (most of the time; some of our customers host it themselves, and in that case, we support their internal team), provide 24/7 monitoring and support, fix bugs, and develop updates and enhancements. IoT applications, unlike the typical “phone app”, have long lives—years in most cases—and it means a lot to maintain that continuity with the same team that designed and built the application. So we’re in it for the long run.
It ultimately translates into speed, cost, expertise, and low risk.
Why should we use ObjectSpectrum instead of the web development company we used to do our very complex website project?
See the FAQ titled, “Why use you instead of a custom software or an internet application development firm?” It’s the same answer, just replace “software outsourcing firm” with “web development firm.”
But specific to this question: what they’re doing in a very complex web application project is just very, very different from an IoT project. It’s not what they do. We aren’t saying it is impossible for someone that has web design and e-commerce experience to also have IoT experience, but it’s highly unlikely that their IoT experience would be very deep or wide. The vast majority of companies that specialize in web, e-commerce, and mobile applications simply have not had the exposure to a true IoT application. This is also part of the challenge: the term “IoT” can be used very broadly. Somebody might say, “I wrote an app that lets someone see the pollen count in their zip code and that’s an IoT application.” No, that’s a mobile app. There’s no IoT there whatsoever, but someone will tell you the opposite when trying to sell you on using them. It really does boil down to expertise.
We aren’t saying it isn’t possible, but we are saying it’s unlikely they have the expertise because, frankly, it’s just a different skill set. You can be an amazing musician and know how to play the trumpet, the trombone, the tuba, the French horn and all other brass instruments, but that doesn’t mean – with all the expertise in the world as a musician – you will be an expert at the viola. In fact, odds are, you won’t have a clue about playing the viola. You wouldn’t go to the foremost musical expert in the world who plays brass instruments and expect her to teach you about string instruments. And yet, we see that happen frequently – especially when that company is not terribly technical. They ask themselves, “who do we know that’s technical – oh yeah – we should call the company that built our website. That was technical!” It’s the only technical company they know. And then they call that company and say they want to build this application with all these sensors, etc and the sales guy is like, “Oh heck yeah, we can do that!” – ‘cause they’ll say yes to anything – and then two years later they’ve spent five times their initial budget and they won’t have anything that actually works. This happens literally all the time. If someone came to us and asked us to build an e-commerce system, we’d simply say “no.” And that’s not because we don’t have some idea about how e-commerce works. It’s because we focus on IoT. That is our expertise–the many complex layers of IoT–and that’s what we do. That’s all we do.
Sales
Does ObjectSpectrum support devices with Hazardous Area certifications?
Yes, we do. That’s really about the device itself. So, if we had an application that had sensors for a hazardous environment, we’d have to support devices with Hazardous Area certifications. But from our perspective, it doesn’t really matter that much because Prism is not in the hazardous environment. Your solution is almost always in the cloud. The exception would be on-premise deployments or certain edge computing hardware, and of course, options generally exist for those that have Hazardous Area certifications, too.
Is a long-term contract required?
Not required, no. Typically, we sign a three-year, renewable contract. This works well for both parties. Some customers want longer contracts to lock in pricing, SLAs, or some other aspect of the service, which we are happy to accommodate.
What ongoing costs of running an IoT solution should I plan for?
Whether we host the application or you do, there is an operating cost which includes computer equipment, services, connectivity, support, updates, security patches, maintenance, backups, etc. After all, servers require care and feeding. That cost is part of it, and this is one of the benefits of, and why most of our customers prefer, that we host the application—so that the costs of that can be very well understood and the economy of scale comes into play because we’re not just doing this for you, but we’re doing it for all of our customers. This is why hosted services and Software as a Service (SaaS) are as popular as they are—there’s a real advantage to doing it this way. We didn’t invent this idea, but it’s usually the best solution. But, if you choose to do it yourself, you have to be realistic about what those costs are. There are both recurring technical costs and there are manpower costs to hosting and managing an application. Especially something that needs to be online 24/7. So that’s obvious.
The other part is support for the end-users of the application and maybe (depending on the nature of the app) dealing with sourcing or manufacturing, provisioning, and shipping of devices, dealing with customer service issues, returns, replacements—just all the normal logistics. That’s going to vary based on the nature of the application, but that is definitely an ongoing cost. Some companies choose to do this themselves, while others prefer to let us handle the whole thing for them—this is what we call IoT as a Service.
The last category is that there are almost always additional enhancements and normal maintenance of the software that went into the solution. It’s very rare, if ever, that you have an IoT solution that is never updated or has a feature added or some other sort of enhancement that goes into it. So you should always budget for future features, enhancements, and maintenance of your application. This is a case where most of our customers will have some combination of a fixed monthly budget of development hours that we have and we just chip away at a list of features and enhancements they want over time, and/or they’ll have new milestones where they say, “okay, we’re going to add these 20 features,” and then it’s just a new development project with an estimated cost like the original development project.
So, in summary:
- Ongoing operating costs associated with hosting
- Ongoing operational costs associated with the solution
- Ongoing software maintenance and feature updates
How long will it take to develop and deploy an IoT solution?
It depends, of course. A proof of concept can often be done in less than thirty days. Depending on the scope and complexity of a complete solution, it could run from three months to a year. While there’s no “typical application,” somewhere between three and six months is common.
How much does it cost to develop an IoT solution?
It depends on the scope of the solution, of course. It’s hard to give a range, but smaller solutions that have very common functionality that are using off-the-shelf hardware (so software only), could be done for as little as $25,000. Larger, more complex solutions are obviously going to cost more (it’s rare, but they could go into the hundreds of thousands of dollars). Typically, the development cost of a solution is between $50,000 and $100,000 – just to give you a general ballpark. We’re probably not going to do anything that’s less than $25,000. The only way to know for sure what your solution would cost is for us to talk to you about it, so call us or use our contact form now, and we’ll give you a more specific answer.
Does ObjectSpectrum develop mobile applications, or just cloud and web-based applications?
Well, it depends on the requirements of the project, but the overall answer is yes. They typically fall into two categories: 1) Progressive Web Application (PWA) – a web-based application that is designed to run on a phone. In some cases, this is the best solution for “mobile”. 2) A Native Application (for Android and iPhone) – this is a mobile application, proper. If a native application is required, we have that capability as well. When people think of a mobile app, they’re usually thinking of an app they can download from the App Store. But that might not always be the right answer.
Apps that run through the App Store require quite a bit of specialized programming, and the approval process can be time-consuming. If you need that, we can absolutely do that for you. If you’re not sure, we can show you the options and help you decide. Our modus operandi is not to immediately say yes just for the sake of the sale. We want to understand exactly what your business needs before we jump into development.
Does ObjectSpectrum ever work alongside another company to create a solution?
There absolutely are times where there are two or three companies working very closely together. This is different than when we have a point solution where we bring in outside companies with some specific expertise. This is where someone says, as an example, “I’ve already picked out my hardware design firm and they’re already halfway down the path of building the device. We need you, ObjectSpectrum, to come in and build the software and make sure the integration is going to work.” Then we are working alongside an outside company, but that’s because that is what the situation called for. So, yes. Sometimes we do, and yes – we are always open to this when that’s what is needed. And the same is true for UI stuff – where a customer was already working with a design firm that they already used for their corporate identity and they asked, “Hey, we want you to work with our design firm because they’re going to design the wireframes and do all the graphics and do all the assets – could you work with them to incorporate what they do into our solution?” and of course the answer to that is also “yes.”
Does ObjectSpectrum offer a “white label” option?
Yes, and really everything we do is a white labeled solution. We aren’t in the business of selling an end-user product. Our logo doesn’t go on your solution. Everything about the look and feel, theme, styling, etc is going to be your identity – built to your specifications.
Can I get a demo?
Yes. Please. You should. Absolutely. We love giving demos because our ability to help you will be self-evident. You can request your demo right here.
Does ObjectSpectrum offer a Service Level Agreement (SLA)?
Yes, we offer an industry-leading SLA.
What cloud infrastructure provider does ObjectSpectrum use?
Our standard cloud infrastructure provider is Amazon Web Services. We’ve used them since the beginning, we have experience with them since they started back in 2007, and we like them a lot. But – we are completely cloud-agnostic. If you wanted a dedicated cloud environment as opposed to running your solution in our shared tenant cloud environment on Amazon, we can run on any cloud infrastructure provider that offers Linux virtual machines. And that includes physical infrastructure providers, too.
Does ObjectSpectrum offer UI/UX design services?
As part of a project, yes. We do not offer these as standalone services.
Can ObjectSpectrum create a Proof of Concept (PoC) solution for validation of an idea?
Yes, in fact we recommend it. There are usually unanswered questions at the start of a project, so this is the best way to start a project. Prism is designed to build large-scale, highly customized IoT applications. But it can also be used to do quick prototypes. And the way that you do that is you focus on the specific functionality that you’re trying to test – the questions you’re trying to answer – and you don’t worry about all the other stuff that goes into the solution. As an example, if what you need is quick data collection with some analytics, maybe some visualizations, then don’t waste your time building the entire end user provisioning system and the billing system and the user management system—don’t do any of that. That all has to come at some point, but focus on just the part that matters – the primary questions you have. In a PoC, you are not trying to make it look pretty. You’re just trying to get your questions answered quickly and easily. Prism is designed to be able to work like that.
Can ObjectSpectrum provide AI/ML capabilities as a part of a solution?
Yes. Machine Learning is a subset of Artificial Intelligence, and Machine Learning is what people are usually talking about when they say AI. But we digress. Machine Learning has many different types of applications, and we will have a Machine Learning expert specific to your solution’s needs.
What skills does my company need in order to work successfully with ObjectSpectrum?
In most cases, what we’re looking for from the customer is somebody that has expertise in the subject matter – someone with domain expertise in the area of whatever the solution is. If it’s a solution for ranchers, we need someone with deep ranching expertise.
Locating & tracking assets is important to my business. Can ObjectSpectrum provide this capability?
Yes. When you talk about asset tracking, that’s a very generic term. One of the built-in capabilities of Prism is the underlying building blocks of asset tracking, which includes things like GPS coordinated math and mapping, visualizations, geofencing logic, etc. But the advantage of using Prism and ObjectSpectrum comes when you get past the basic idea of GPS locating and asset tracking. This is where your specific needs come into play – what exactly are you tracking? Is it outdoors, is it indoors, is it something that needs to go anywhere in the world? Is it something that only moves around in a campus or a factory? Are you keeping track of more than just its location? Do you want to know information from other sensor inputs on it with data that needs to be tracked and reported? When you get into the specifics of an asset tracking application, that’s usually where we have a big advantage that we can bring to the table, because we are certainly more than just an asset tracking solution.
Does ObjectSpectrum provide application hosting?
Yes. In fact, that is the most typical deployment model for most customer solutions.
Does ObjectSpectrum work with other design, development, or engineering companies or do we do everything in-house?
Yes, we work with other companies when the situation calls for it. One of the benefits of working with ObjectSpectrum is that we have relationships with a large number of outside companies that we’ve worked with before that have specific expertise. We know who to go to when we’re dealing with a particular thing for which we need expertise. If we need somebody on the hardware side to design a specialized antenna, we know who to go to that is an expert in antennas. If we need a graphic product logo, we know just the designer to do that. These are just resources in our Rolodex® that we have experience working with and, given all of the details of a project, we will look at those things that we know are going to be beneficial for the customer to bring in people from the outside who have specific domain expertise on certain aspects of that project.
Does ObjectSpectrum offer support?
Nope, you’re on your own, sucka. Okay, okay – yes, of course we do. As part of us hosting your solution for you, support for you is included within that service contract. If you are licensing our software, support is also provided as part of that licensing contract. And while those options don’t include support to your end customers, end customer support is one of the optional services you can choose (as part of our IoT as a Service offering).
Does ObjectSpectrum offer turn-key private wireless networks?
Yes. This is especially true for applications that have a specific geography. This could be on a farm or in a building or on a campus where the solution is well suited for a private network and the private networks can include things like LoRaWAN as well as private LTE or even in some cases, private WiFi or Bluetooth networks. Obviously, it depends on the application, but when it makes sense, we can and do provide the network and the management of a complete network solution.
There have been prospects in the past that have assumed “If I am using a public network, I’ll have to pay for it, but if I’m using a private network, it should all be free, right?” Nope. Not right at all. Think of the network as one part of your overall solution. If we use a public network, then that public network needs to provide service to you, and they will charge you some type of recurring fee to do that. If we build a private network for you, we still have to provide that service, so there’s some kind of fee whether it’s built into our monthly rate, or the fee associated with the number of devices that you have, but it’s not free. Just because it’s private does not mean there’s no cost to it. Somebody has to actually operate it. Now, typically the cost will be less for a private network than a public network, but in some cases you have to use a public network because there is no other choice.
Can ObjectSpectrum integrate with public wireless networks?
Yes, including everything from cellular carriers to public LPWAN providers. We are already pre-integrated with all of the major carriers in this space (like AT&T, Sprint, T-Mobile, Public LPWANs, different regional LoRaWAN providers, etc).
Does ObjectSpectrum support the integration with third-party software and services?
Yes. We will integrate with any normal modern API that’s available for any other third-party services. There are two directions: 1) we provide a number of different options and industry-standard protocols and APIs to allow other systems to act as data and functionality within your application, and 2) we also will integrate with any normal modern API that is available for any other third-party services. One of the things that we’ve done is we’ve pre-integrated with a number of third-party services that make it faster and easier to build a solution, including things like weather data from the national weather service or satellite imagery for mapping applications or the ability to send and receive text messages. Those are third-party services that we’ve already pre-integrated to, but those aren’t the only ones we can integrate to. We have a very open system that allows anyone to integrate with us and we can accommodate integrating any other third-party API on an as-needed basis. We’ve just pre-integrated a bunch of stuff that’s common.
Does ObjectSpectrum offer software licensing?
Can I do my own development using your platform (Prism)?
Yes, although most of our customers don’t because they are looking for our expertise to accelerate their time to market. There is a learning curve to building an application with Prism, and we’re not really offering a drag-and-drop WYSIWYG tool here. It’s not meant for any developers to pick it up and have an IoT solution created in minutes. This was built for developers on the back-end and the UI/UX people on the front-end. So, if you have those resources on your staff, they could absolutely learn Prism, but the vast majority of our customers allow us to do it. One common trend is where customers will let us do the turn-key development of the initial product and then they will do their own ongoing maintenance and enhancement from there.
What industries or vertical markets does ObjectSpectrum have experience with?
These are some of the more common industries that we work with. But just because it isn’t listed there doesn’t mean we wouldn’t or couldn’t do it. We work with IoT, not a specific industry. If you need IoT and you’re in a different industry than you see here, you need us. Because you need IoT.
What services does ObjectSpectrum provide?
Consulting, Design (product, software, firmware, application, UI/UX), Development (software, firmware), Application Management (hosting your IoT solution, the ongoing management of it, supporting software services). To that last point, when we host someone’s IoT application, it’s not like we have one server hosting that IoT application. It runs across many different servers and uses many other servers that provide services (like everything from email to text messaging, to message brokering to database, etc.) so it’s a big environment that has dozens of servers that are all there to support your application. We also provide something we call IoT as a Service, which is a full turn-key outsourcing of the ongoing operations of an IoT deployment, providing as much or as little of the ongoing operations as you like.
What kind of companies are typical of ObjectSpectrum customers?
The bulk of our customers are Original Equipment Manufacturer (OEM) companies that are 1) looking to bring a new product/service to the market or 2) want to add IoT capabilities to an existing product or service that they already offer. These are typically mid-size and larger companies, and sometimes “well-funded” start-ups.
A secondary category making up a smaller portion of our customers are enterprise companies that are big enough to justify the cost of custom-developed solutions for their own us.
Check out this page to see if you fit into the types of customers we usually work with.
Does ObjectSpectrum comply with industry regulations for medical applications (like HIPAA)?
Yes. And for our customers that are bound by HIPAA, we regularly sign a Business Associate Agreement (BAA).
Are solutions developed by ObjectSpectrum GDPR and CCPA compliant?
Yes. We are well-versed with both of those regulations. Specific details of compliance are often dependent on the nature of the application, but if your application needs to operate within those regulations, we have experience developing applications that do. If you give us a set of requirements that are not GDPR or CCPA compliant, and you’re okay with that, we’ll implement it that way. We’re not forcing you to be compliant. But if it’s necessary for you, we can and will accommodate that for you. We are not implying that we have some sort of “GDPR button” that we push and then we’re done. It requires custom work to make sure the application is compliant – there are fundamental things we have to take into account when designing an application – but we have done that and will do that when required. If you don’t take them into account and you don’t understand what you need to do to meet those requirements, then it can be very expensive to retrofit it later. If you do understand it and you want to be compliant, then we have the expertise. We know what to do to build it into the application from the ground up.
When ObjectSpectrum develops an IoT solution, who owns it?
You do. When we build it, we will use both third-party software and our own software (Prism) as part of building the solution. Those third-party pieces might be open-source, or they might be commercially licensed (and of course we’ll let you know what tools we’re using), but the application that ObjectSpectrum builds to your specs belongs to you, the customer.
Who owns the data that is collected or derived from my IoT solution?
You, the customer, do.
Can I host the solution in a cloud provider of my choice? Or on my own servers?
Yes and yes. We love a good, simple answer.
Why use ObjectSpectrum instead of a custom software or an Internet application development firm?
There are three issues here:
- ObjectSpectrum has our own software and tools that were purpose-built to rapidly design, develop and deploy IoT solutions. That is our secret (or not so secret, since we’re putting it on a public website) weapon. If you go to a software outsourcing firm, they are going to use tools, development environments and third-party components and whatnot that they know and that are available to them in the market. They’re not bringing any intellectual property of their own to the table. We’re bringing intellectual property that was purpose-built to accelerate these types of solutions and not only for the purpose of making it go faster, which directly translates into less cost, but also in reducing risk. In the sense that, when we develop a solution, we are using a set of tools and libraries and both in-house developed and third-party stuff that already works together and has already been field-proven and tested. We already know that it’s secure. We already know that it scales. We already know all of this stuff about it, whereas a custom developer has to figure that out about every single aspect of even the tiniest components they create as a part of the solution. In a sense, nobody starts from scratch these days – ‘cause what does “from scratch” mean anyway? But the difference is that we’re starting you five years ahead of where you would be starting without us. Way ahead. Our starting point is 80% of the finish line compared to the 0% starting point of any software outsourcing firm would be starting from.
- They may not have a lot of experience in IoT. Maybe they’ve developed complex games, or maybe they’ve developed complex e-commerce websites. However, the skillset to create applications like those are not the same skillset required to create IoT applications. There can be some overlap, but not necessarily. Do not be fooled by promises made by sales engineers who say, “We can do this, we can do that, we can do IoT.” IoT is very different. It’s a very deep “stack” with many layers – much more so than an e-commerce site. But even if you don’t want to compare them, you can just say that they’re very different. We wouldn’t use Prism (our IoT solution platform) to write a first-person shooter game, for example. And it’s also about expertise. We are specifically and solely focused on IoT, we have deep experience at all levels of the stack, we have strong relationships in the ecosystem (vastly undervalued by some), and we know what it takes to design, develop, and deploy an IoT solution having focused on solely those since 2016.
- Unlike typical custom software development firms, we become our customer’s software partner. That’s a lot of talk in many cases, but for us, it means that we host the application (most of the time; some of our customers host it themselves, and in that case, we support their internal team), provide 24/7 monitoring and support, fix bugs, and develop updates and enhancements. IoT applications, unlike the typical “phone app”, have long lives—years in most cases—and it means a lot to maintain that continuity with the same team that designed and built the application. So we’re in it for the long run.
It ultimately translates into speed, cost, expertise, and low risk.
Why use ObjectSpectrum instead of an IoT SaaS company?
ObjectSpectrum is primarily a software engineering company, focused on creating IoT solutions. We are more like a traditional software outsourcing company than a SaaS provider. An IoT SaaS company is primarily looking for a customer that wants to do it themselves and is willing to operate within the constraints of their software. The closer you get to a tool that can be used by non-software engineers (i.e. application designers and developers), the more you will have to play by the rules they have created in their software. Their software will let you take your knowledge of your warehouse, for example, and combine that with their software to connect and monitor this thing and that thing, and that’s great. But by targeting that kind of a user, you are going to be putting constraints around what you can do. And for some people, this may be completely fine. That might be the best choice for them and their situation.
If you are an enterprise customer, and what you need is to collect data from a hundred different sensors in your factory, or GPS trackers on your hundred different pieces of heavy equipment, then an IoT SaaS company could be okay for you because it will let you build a functional application. But the problem is that you are still going to be working within those constraints. To be clear, we are not knocking the idea of you working with an IoT SaaS company. We are just stating what’s different about that type of company and ObjectSpectrum. It’s important for you to understand the differences so that you can make the best choice for your specific situation.
But the dirty little secret of any SaaS company is that if you need to go beyond the scope of capability that they deliver to you, you either a) have no choice because they didn’t provide you with a way to extend it, or b) you now need to bring in the hardcore developers that are necessary to go beyond that set of functionality provided with the software. If you’re trying to build an application that is going to be offered for sale, either as a standalone service or as part of something that you’re selling, you want something that is a lot closer to from-scratch software development. You want something that doesn’t have those constraints; you need something that isn’t designed for a non-technical user. Because you’re going to run into issues with the SaaS products where they simply don’t meet your needs, and then what do you do? So the target audience for this is typically someone who is using it internally and they’ll tell you, “oh no, you can white label it, put your logo on it and offer it to your customers,” and that’s all great. If what you actually need is what they thought you needed, you’re in good shape. But as soon as you cross that line, you’re now into having to bring in the technical people to actually get the job done.
The bottom line is that an IoT SaaS company is not in the business of IoT solutions engineering. It is in the business of licensing a piece of software. ObjectSpectrum is in the business of solutions engineering. Tools like an IoT SaaS company can be a great prototyping tool. Because once you learn how to use their tool, it can be very quick and easy to set up, “okay, we need to monitor these five sensors and we need to test this thing over the next two weeks” and that type of stuff. It can be a great prototyping tool. Unfortunately, with most IoT SaaS companies, it comes with a pretty high price tag just to license it. So that makes it kind of an expensive prototyping tool. That’s not the case for every single one of them (IoT SaaS companies), but it is with a lot of them.
Why should we use ObjectSpectrum instead of the web development company we used to do our very complex website project?
See the FAQ titled, “Why use you instead of a custom software or an internet application development firm?” It’s the same answer, just replace “software outsourcing firm” with “web development firm.”
But specific to this question: what they’re doing in a very complex web application project is just very, very different from an IoT project. It’s not what they do. We aren’t saying it is impossible for someone that has web design and e-commerce experience to also have IoT experience, but it’s highly unlikely that their IoT experience would be very deep or wide. The vast majority of companies that specialize in web, e-commerce, and mobile applications simply have not had the exposure to a true IoT application. This is also part of the challenge: the term “IoT” can be used very broadly. Somebody might say, “I wrote an app that lets someone see the pollen count in their zip code and that’s an IoT application.” No, that’s a mobile app. There’s no IoT there whatsoever, but someone will tell you the opposite when trying to sell you on using them. It really does boil down to expertise.
We aren’t saying it isn’t possible, but we are saying it’s unlikely they have the expertise because, frankly, it’s just a different skill set. You can be an amazing musician and know how to play the trumpet, the trombone, the tuba, the French horn and all other brass instruments, but that doesn’t mean – with all the expertise in the world as a musician – you will be an expert at the viola. In fact, odds are, you won’t have a clue about playing the viola. You wouldn’t go to the foremost musical expert in the world who plays brass instruments and expect her to teach you about string instruments. And yet, we see that happen frequently – especially when that company is not terribly technical. They ask themselves, “who do we know that’s technical – oh yeah – we should call the company that built our website. That was technical!” It’s the only technical company they know. And then they call that company and say they want to build this application with all these sensors, etc and the sales guy is like, “Oh heck yeah, we can do that!” – ‘cause they’ll say yes to anything – and then two years later they’ve spent five times their initial budget and they won’t have anything that actually works. This happens literally all the time. If someone came to us and asked us to build an e-commerce system, we’d simply say “no.” And that’s not because we don’t have some idea about how e-commerce works. It’s because we focus on IoT. That is our expertise–the many complex layers of IoT–and that’s what we do. That’s all we do.
Why use ObjectSpectrum instead of my internal development team?
Well, does your internal team have this skill set? Are they deeply experienced in IoT design and development? Maybe they’ve been doing database development for your ERP system. Are they the best people to develop an IoT application that they themselves know nothing about it? Of course not. But okay, let’s presume your internal development team does have the skillset. But then we’d ask why not let us work with your internal development team? Let us be the expertise in the IoT side of this and let your internal team be the experts in your business. And, under the right circumstances, eventually your internal development team could take all of it over. We’re using all kinds of industry-standard tools and languages and protocols. It’s not that someone couldn’t learn it, it’s just do you want to pay for your internal team to go through that learning curve? We can short-circuit that process and then you always have the option of letting your internal team take over maintenance and future development.
After you have created the solution for us, how do we know that someone else (internal or external) can understand your code and take it over to maintain the solution?
This is actually one of our big advantages: by building applications on Prism, there is an inherent structure to it – it was designed to be a rapid application development tool. That doesn’t mean throwing crap at the wall in order to speed it up. We have the capability of doing this very rapidly because the environment is so rich, but it also imparts a structure so that – for long-term maintenance (whether we are doing it or your internal team is doing it) – it’s manageable. It’s not a piece of spaghetti code that someone created that – when the next developer looks at it – doesn’t make sense and requires a lot of unraveling (which is a common situation with custom development shops or individuals).
What pricing model do you use for your IoT solutions?
What pricing model do you use for your IoT solutions?
Well, first let’s exclude IoT as a Service in this answer. It’s not a requirement in our solutions, and it is priced based on what you want us to do for you.
There are two different pricing models for our IoT solution projects:
- Managed Hosting. This is similar to a typical SaaS model, but it’s different in the sense that it not one-size-fits-all. We are hosting and managing your custom-built solution. In this model, there are two categories of costs:
-
-
- Upfront Development (one-time). This is based on the requirements of your solution. Those requirements could include software, hardware, and/or third parties contributing different components to the solution. All of these will go toward the upfront development cost of your IoT solution.
- Managed Hosting (ongoing). This is billed to you on a subscription basis, where the pricing is based on the size of your application (we have between one and six different metrics that determine what this price is, depending on the nature of the application). If it’s only one metric, this would probably be “by device.” So, for certain applications, that’s all we really care about – how many devices do you have? For other applications it might be based on the “class” of device (i.e., is this a simple temperature sensor or is it a camera delivering very high bandwidth 4K video? The price will differ between those because there is a massive difference in the load required to support them.) And other times – if the nature of the application is such that large numbers of users are logging in and spending a lot of time in the application – then the hosting fee is based on a per user basis. On the flipside, if the application is such that very few users log in (perhaps the interaction with users is lightweight) or maybe it’s something where there are hundreds of thousands of sensors (devices) but only two users, we would price it per device. So, it’s hard to pin it down without understanding what we’re building for you when answering this. Ultimately it all boils down to the scope and size of the application, and that’s what determines the subscription cost for us to host and manage the application. Essentially it is a “pay for what you eat” model. It’s just that the “food” your solution is “eating” is custom to your own solution. If your solution doesn’t eat much, you won’t be paying much for its food.
-
-
- Self-Hosted. This differs from the Managed Hosting model above because instead of ObjectSpectrum hosting and managing your solution, it would be you hosting and managing your solution – either on a cloud provider of your choice or in your own data center. The vast majority of our clients do not choose this route because they’re almost certainly looking at tens of thousands of dollars a month on day one for a self-hosted application just for the team they’ll (or you’ll) need to manage it. In this model, we are effectively operating within a traditional software licensing model. You’re responsible for the solution. You are hosting it and managing it wherever you want. But we’re licensing our software to you, just as if you had licensed Oracle or Microsoft Windows, for example. The reality is that companies are going to be much better off letting us host their solution (a la Option 1 above). This is true at least until they reach a scale that starts to justify them having the overhead and resources to manage it in-house. The only exception to this would be if you had a company that had such a strong need to have control of it on your premise – regardless of the cost.
As mentioned, the most common pricing model is that we host it and manage the solution we build with you (#1 above) because it’s the most economical, the easiest to get started, it doesn’t require any technical expertise on your part, doesn’t require any personnel on your part, and it’s a turn-key service that grows with you. You also never have to worry about back-ups, servers, security patches, and so much more.
A Note on Pricing Models in General: there will typically be ongoing software development (for updates, features, etc.) that continues after any solution is deployed. This is normally billed on an hourly basis where you are buying blocks of hours. There are two ways to structure the fees for ongoing development: 1) as a monthly budget, like a retainer, or 2) as a subsequent, clearly-defined project.
How do you price your IoT as a Service offering?
IoT as a Service is designed to be a fully-managed way to deploy and support an IoT solution. Essentially, we handle everything (or at least as much as you want us to handle). This can include things like end-user support/helpdesk, logistics (sourcing, warehousing, order management, shipping, returns, etc.), and even product management. As a result, pricing for IoT as a Service is highly customized, based on your needs.
Are you open to a success-based component to your compensation?
Yes, under the right circumstances. We have and will do this for the right opportunity, though this isn’t typical. But we have some examples of having done that and would be open to it under the right parameters.
What if we are in another state? Country? Halfway around the world?
No problem.
What if we need our application’s user interface to be written in a language other than English?
No problem. The Prism platform was designed from the ground-up for different languages and for full internationalization – including the same application having multi-language support.
I’m not technical and I do not have a trusted technical resource. How do I know you can do what you say you can do?
This is a common dilemma: a non-technical person/company trying to make a decision about what technical team to rely on for a technical purchase of any kind. We don’t have a magic bullet answer for that, but we can say that we can talk about what you’re trying to do with you and you can let us show you how our expertise translates to that. We think we can make you feel comfortable about it without having to understand all of the technical underpinnings.
What kind of guarantees do you make?
All development work is broken into phases on progress payments. We aren’t asking anyone to pay for 100% of the solution upfront. That helps ensure you don’t pay for too much before you see the progress being made. You are under no obligation to continue to the next phase if you are not satisfied with our work.
I’ve read that half or more IoT projects fail. How can I make sure my project succeeds?
Well, first of all, use us if you want to ensure it will succeed. A lot of IoT projects fail because they had wildly ambitious scopes, they had ill-defined project objectives, they were developed by people with no prior experience doing this – and these are just a few of the reasons. At the end of the day, you need a strong partner that can help you not only develop the solution you’re looking for, but also help you design and develop the requirements that make up that solution so you don’t end up as a statistic. That’s what we do with every project.
Is IoT right for my company?
Maybe? We have to talk to you first, of course. But, because the technology that goes into building an IoT solution has become lower cost and more accessible today, more companies could probably benefit from IoT than could have five years ago. To really know, we invite you to reach out to us and help us understand the particular problem you’re trying to solve. There is a better than probable chance that the answer to this question is yes.
Technical
How can Blockchain technology be used with IoT?
Blockchain is not directly related to IoT. It’s a technology that – in some applications – can be used as part of an IoT solution. There are a number of different possible use cases, ranging from payment processing using cryptocurrencies to things like smart contracts, which use blockchain ledgers to exchange information securely between trading partners. Blockchain creates an unalterable record of something that has happened, which is why it is used for cryptocurrency. But in IoT, we might need an unalterable record of some sensor value and that doesn’t have to have anything to do with cryptocurrency. It’s a way for everyone to trust that the information is accurate. While not every IoT application has a need for blockchain, we have quite a bit of experience leveraging various blockchain technologies in different IoT solutions.
What is Declarative Development and how can it shorten development time?
Declarative means you are not writing “functional” or “procedural” code to do something. Instead, you are declaring what you want to happen.
The main example of a declarative approach within Prism is Prism View. For example, instead of writing code that tells the browser how to draw a bar graph, the UI/UX person that is developing the UI part of the solution declares how they want that bar graph to appear. They are saying, “I want a bar graph, I want it to be here, I want it to be this size, I want it to use these colors, I want it to have these labels, I want it to pull from this data.” That’s what declarative programming is. You are declaring what you want to happen, you are not writing software to make it happen. The advantage is that it’s faster to develop, it’s less error-prone, and it’s easier to maintain over the life-cycle of the application.
Another example is our Binary Schema module, used to decode packed binary data payloads, typically received from sensor nodes. While it runs in Prism Core and Edge, which are not declarative environments, the process of building a payload decoder with the Binary Schema module is itself declarative. So instead of writing code that procedurally extracts data from the binary payload (which can quickly turn into some real spaghetti code), the developer simply declares the desired result: data in the form of meaningful named properties. And as with Prism View, this approach is faster to develop, less error-prone, and much easier to maintain and modify.
Does ObjectSpectrum support devices with Hazardous Area certifications?
Yes, we do. That’s really about the device itself. So, if we had an application that had sensors for a hazardous environment, we’d have to support devices with Hazardous Area certifications. But from our perspective, it doesn’t really matter that much because Prism is not in the hazardous environment. Your solution is almost always in the cloud. The exception would be on-premise deployments or certain edge computing hardware, and of course, options generally exist for those that have Hazardous Area certifications, too.
What is LoRaWAN?
LoRa stands for “long range,” so it the word literally means “long-range wide area network.” It is a low-power WAN modulation technique that uses license-free frequency bands to transmit small amounts of data – either over long distances (ten miles or more) or through obstructions like buildings, typically being able to penetrate several concrete walls. It’s used in a lot of applications, including agriculture, smart buildings, smart cities, where you need either the long-range or the deep building penetration capability to wirelessly collect data from sensors and/or wirelessly send commands to actuators. It is often used in applications that need to be very low power, like battery-powered devices that last five years or more on a battery, or energy-harvested devices, like devices that run on solar power virtually forever. It’s a wireless technology that can either be operated on a private network or on any one of a number of public networks that provide LoRaWAN connectivity for a monthly fee. LoRaWAN is one of the wireless technologies that we use at ObjectSpectrum, and often includes network management services for private LoRaWAN customer networks as part of the solution. We are also member of the LoRa Alliance, which certifies LoRaWAN devices.
Is Prism built as a “high-availability” architecture?
Yes. Prism consists of the core services that implement things like the microservice environment that runs the application, and it also includes other services that are used to support the application (like message brokers, databases, and so on). The architecture for each of those different systems is designed for high availability using the particular high-availability approach that is suitable for that particular system. In the case of a database, this might be to have a cluster of three database servers that are all working together so that if you lose one, you haven’t lost anything. The high availability for a message broker might be that you have two different message brokers and either one can handle the expected message volume. For any given subsystem, there will be a way to implement that subsystem in a high-availability architecture, which we always do in our hosted environments. Another term for this is “fault tolerant.” It just means it can tolerate a fault without adversely impacting the application. High availability really means the same thing. You want the service to be highly available (24/7), so you architect the system with high-availability design rules. You want to make sure the service it provides is highly available even if parts of it fail.
What wireless standard is best?
Well, “best” for your solution is different than “best” for someone else’s. And ObjectSpectrum is not tied to any particular wireless or connectivity standard of any kind. We regularly use a number of different technologies, and that is part of the design phase of any solution – to determine what the right technologies are for a given solution. Of course, that’s true no matter what technology we’re talking about (not just the wireless standard). Tracking ships at sea will necessitate a very different wireless technology than something that needs to keep track of pallets in a warehouse. It just depends, but we are not tied to any particular technology.
What third-party sensors and devices does ObjectSpectrum support?
ObjectSpectrum supports just about any third-party sensor and device. We have the ability to rapidly integrate new devices. We aren’t limited by any particular list or kind of sensor or device. We figure out what the best solution is for what you’re trying to do, and we are completely agnostic when it comes to the device or any other technology it uses. We can integrate devices from different manufacturers with different technologies so that we can use the best in class for your specific solution’s needs. As a general rule, we try to use off-the-shelf sensors and devices whenever possible, but will work with our partners to develop custom hardware when that’s needed.
What web browsers and mobile devices does ObjectSpectrum support?
All modern browsers and mobile devices.
What cloud infrastructure provider does ObjectSpectrum use?
Our standard cloud infrastructure provider is Amazon Web Services. We’ve used them since the beginning, we have experience with them since they started back in 2007, and we like them a lot. But – we are completely cloud-agnostic. If you wanted a dedicated cloud environment as opposed to running your solution in our shared tenant cloud environment on Amazon, we can run on any cloud infrastructure provider that offers Linux virtual machines. And that includes physical infrastructure providers, too.
Is a cloud service always required for an IoT application?
No. There are cases where there is a cloud connection, but the cloud connection is primarily there to collect data for analysis, and the function for the application that it is performing is completely local. That might mean that the application is running entirely on the phone, or it might mean that there’s some local process, computer, or device that’s actually running the application, so it doesn’t need the cloud to operate. It can connect to the cloud if the cloud is available, but it doesn’t rely on the cloud to operate and do its job. It’s an application that can run self-contained if it doesn’t have connectivity to the cloud.
Locating & tracking assets is important to my business. Can ObjectSpectrum provide this capability?
Yes. When you talk about asset tracking, that’s a very generic term. One of the built-in capabilities of Prism is the underlying building blocks of asset tracking, which includes things like GPS coordinated math and mapping, visualizations, geofencing logic, etc. But the advantage of using Prism and ObjectSpectrum comes when you get past the basic idea of GPS locating and asset tracking. This is where your specific needs come into play – what exactly are you tracking? Is it outdoors, is it indoors, is it something that needs to go anywhere in the world? Is it something that only moves around in a campus or a factory? Are you keeping track of more than just its location? Do you want to know information from other sensor inputs on it with data that needs to be tracked and reported? When you get into the specifics of an asset tracking application, that’s usually where we have a big advantage that we can bring to the table, because we are certainly more than just an asset tracking solution.
What skills does my company need in order to work successfully with ObjectSpectrum?
In most cases, what we’re looking for from the customer is somebody that has expertise in the subject matter – someone with domain expertise in the area of whatever the solution is. If it’s a solution for ranchers, we need someone with deep ranching expertise.
What are the advantages of no-code development environments?
There is some confusion around what people mean when they use the term “no-code” (and also “low-code”). The idea, theoretically, behind no-code is that you do not need to be a programmer to use it. The problem with that concept is that some of the things that you are doing within a no-code environment actually does involve defining logic. But you’re typically doing that through some kind of drag-and-drop interface. So instead of writing a piece of code that defines the logic, you’re drawing something like a diagram on the screen, and that’s what defines the logic. So, the question there is, “haven’t we just given you a programming tool that just gives you a different way of programming?” We liken this to a WYSIWYG HTML tool like Dreamweaver used to be. I still had to tell it I want this option field to be a radio button. I want it to have these values, I want these values to mean these things, and I want the submit button to go here and write this to the database. I didn’t have to code it myself with a programming language, per se, but I still was programming in a different way. That is typically what people mean when they call something “no-code.” They mean something you can program through a drag-and-drop interface. And it theoretically does not require any programming skills.
Low-code is kind of a hybrid, where it requires some programming skills, but much of it can theoretically be done by someone without programming skills. So, the problem is that different people in different companies will describe their tools as no-code or low-code without a consistent definition of those terms across different companies and even people within those companies. The bottom line is that – in both cases – this category of low-code and no-code, which typically go together in discussions (which reinforces the fact that there is a lot of confusion between the two terms), they tend to be very highly opinionated environments. Which means that – whatever you’re building – you are going to be operating under the limitations that someone thought you might need when they built their platform. So, if you want to put a chart on the page, then you pick a chart from one of their drop-down meus, they put a chart on the page and they give you three things you can change like the color and the title and that’s it. Highly opinionated just means there are a lot of constraints because the closer you get to no-code, the less flexible it becomes. The other limitation is that – if you want to do something that the tool has not anticipated that you want to do – you probably just can’t do it. You probably have to wait until the vendor of that tool provides it because you have no ability to extend it yourself. Now, some low-code environments will give you a way to extend it, but it’s kind of weird because – if you bought the thing to use it without being a programmer – how are you expected to be a programmer when you get to the things that require a programmer?
They tend to be more suitable for simpler applications and they tend to make for a nice demo. They’ll show you how quickly you can make a page with some charts and gauges on it, how to hook it up to a data source and have a running application. But it’s typically a rather simple application that doesn’t involve anything that’s too far outside of what the capabilities are of the tool and isn’t particularly complex when it comes to the logic that it encapsulates.
The potential benefit to those types of tools is that they can sometimes be used to quickly prototype something. These are often great for prototyping a demo to show your idea’s potential to an investor or your board, for example. So the advantage of it being highly opinionated is that they tend to automatically make a lot of assumptions for you. So you go in and define a data source and the data is coming from wherever and when you drop your chart on the page, it’s usually smart enough to assume that the data is coming from that data source that you specified and it automatically hooks it up for you. As a result of it making a lot of assumptions for you, for doing a quick prototype, it can be useful. But they tend to break down when you go too far beyond simple solutions and basic prototypes and they don’t provide much flexibility when it comes to look and feel and user experience.
Also, just because a no-code environment doesn’t require true programming skills does not mean it doesn’t have a learning curve. The people that do those videos that show them building an app in three minutes? Yeah, they’ve been doing it for years, on that specific platform. It looks super easy because the people who are showing you that have been doing it for a while. They may even be the same people that developed it.
Can ObjectSpectrum provide AI/ML capabilities as a part of a solution?
Yes. Machine Learning is a subset of Artificial Intelligence, and Machine Learning is what people are usually talking about when they say AI. But we digress. Machine Learning has many different types of applications, and we will have a Machine Learning expert specific to your solution’s needs.
Can ObjectSpectrum create a Proof of Concept (PoC) solution for validation of an idea?
Yes, in fact we recommend it. There are usually unanswered questions at the start of a project, so this is the best way to start a project. Prism is designed to build large-scale, highly customized IoT applications. But it can also be used to do quick prototypes. And the way that you do that is you focus on the specific functionality that you’re trying to test – the questions you’re trying to answer – and you don’t worry about all the other stuff that goes into the solution. As an example, if what you need is quick data collection with some analytics, maybe some visualizations, then don’t waste your time building the entire end user provisioning system and the billing system and the user management system—don’t do any of that. That all has to come at some point, but focus on just the part that matters – the primary questions you have. In a PoC, you are not trying to make it look pretty. You’re just trying to get your questions answered quickly and easily. Prism is designed to be able to work like that.
Does ObjectSpectrum offer UI/UX design services?
As part of a project, yes. We do not offer these as standalone services.
Should I use AI or ML in my solution?
Machine learning (ML) is a branch of artificial intelligence (AI) and computer science which focuses on the use of data and algorithms to imitate the way that humans learn, gradually improving its accuracy. AI, or artificial intelligence, is a term that defines a broad category of intelligence – much of which is still highly experimental, or even still solely theoretical. But one component of AI is ML, or machine learning, which is a mature technology that is already in use in thousands of applications across hundreds of industries. And is something that you would often find as part of an IoT solution. As to whether you should use it or not, the real answer is “it depends.” Machine Learning is not a magic bullet or ingredient. Machine learning is a technology like any other that, in certain applications, can add a tremendous amount of value to the solution. And in other cases, it has no place in the solution. We have experience using machine learning. We will look at machine learning as a possible element of your solution when it makes sense to do so. But we have no vested interest in whether we include ML in your solution or not.
Does ObjectSpectrum develop mobile applications, or just cloud and web-based applications?
Well, it depends on the requirements of the project, but the overall answer is yes. They typically fall into two categories: 1) Progressive Web Application (PWA) – a web-based application that is designed to run on a phone. In some cases, this is the best solution for “mobile”. 2) A Native Application (for Android and iPhone) – this is a mobile application, proper. If a native application is required, we have that capability as well. When people think of a mobile app, they’re usually thinking of an app they can download from the App Store. But that might not always be the right answer.
Apps that run through the App Store require quite a bit of specialized programming, and the approval process can be time-consuming. If you need that, we can absolutely do that for you. If you’re not sure, we can show you the options and help you decide. Our modus operandi is not to immediately say yes just for the sake of the sale. We want to understand exactly what your business needs before we jump into development.
Does ObjectSpectrum offer a Service Level Agreement (SLA)?
Yes, we offer an industry-leading SLA.
Is Prism a “no-code” development environment?
Prism – if you look at it in its three different parts – Edge, Core and View: Edge and Core are regular, typical software development environments. They’re not intended to be no-code, they’re intended to be used by an experienced software developer. The language that we use is JavaScript (because it is a common and accessible language), so if you’re using Core and Edge, you are writing JavaScript code (so not “no code”). In the case of View, the target user is an experienced UI/UX designer. There is no code in View (so technically “no code” because View is declarative); instead, there are industry standard technologies that are well known by experienced UI/UX people (things like CSS, SVG, JSON, HTML, etc). To summarize, the different environments – Edge and Core are targeted at an experienced software developer with skills in JavaScript and View is targeted at an experienced UI/UX person with those skills.
Does ObjectSpectrum ever work alongside another company to create a solution?
There absolutely are times where there are two or three companies working very closely together. This is different than when we have a point solution where we bring in outside companies with some specific expertise. This is where someone says, as an example, “I’ve already picked out my hardware design firm and they’re already halfway down the path of building the device. We need you, ObjectSpectrum, to come in and build the software and make sure the integration is going to work.” Then we are working alongside an outside company, but that’s because that is what the situation called for. So, yes. Sometimes we do, and yes – we are always open to this when that’s what is needed. And the same is true for UI stuff – where a customer was already working with a design firm that they already used for their corporate identity and they asked, “Hey, we want you to work with our design firm because they’re going to design the wireframes and do all the graphics and do all the assets – could you work with them to incorporate what they do into our solution?” and of course the answer to that is also “yes.”
Can ObjectSpectrum integrate with public wireless networks?
Yes, including everything from cellular carriers to public LPWAN providers. We are already pre-integrated with all of the major carriers in this space (like AT&T, Sprint, T-Mobile, Public LPWANs, different regional LoRaWAN providers, etc).
Does ObjectSpectrum comply with industry regulations for medical applications (like HIPAA)?
Yes. And for our customers that are bound by HIPAA, we regularly sign a Business Associate Agreement (BAA).
Are solutions developed by ObjectSpectrum GDPR and CCPA compliant?
Yes. We are well-versed with both of those regulations. Specific details of compliance are often dependent on the nature of the application, but if your application needs to operate within those regulations, we have experience developing applications that do. If you give us a set of requirements that are not GDPR or CCPA compliant, and you’re okay with that, we’ll implement it that way. We’re not forcing you to be compliant. But if it’s necessary for you, we can and will accommodate that for you. We are not implying that we have some sort of “GDPR button” that we push and then we’re done. It requires custom work to make sure the application is compliant – there are fundamental things we have to take into account when designing an application – but we have done that and will do that when required. If you don’t take them into account and you don’t understand what you need to do to meet those requirements, then it can be very expensive to retrofit it later. If you do understand it and you want to be compliant, then we have the expertise. We know what to do to build it into the application from the ground up.
Can I host the solution in a cloud provider of my choice? Or on my own servers?
Yes and yes. We love a good, simple answer.
Can I do my own development using your platform (Prism)?
Yes, although most of our customers don’t because they are looking for our expertise to accelerate their time to market. There is a learning curve to building an application with Prism, and we’re not really offering a drag-and-drop WYSIWYG tool here. It’s not meant for any developers to pick it up and have an IoT solution created in minutes. This was built for developers on the back-end and the UI/UX people on the front-end. So, if you have those resources on your staff, they could absolutely learn Prism, but the vast majority of our customers allow us to do it. One common trend is where customers will let us do the turn-key development of the initial product and then they will do their own ongoing maintenance and enhancement from there.
Does ObjectSpectrum provide application hosting?
Yes. In fact, that is the most typical deployment model for most customer solutions.
Does ObjectSpectrum offer software licensing?
Does ObjectSpectrum support the integration with third-party software and services?
Yes. We will integrate with any normal modern API that’s available for any other third-party services. There are two directions: 1) we provide a number of different options and industry-standard protocols and APIs to allow other systems to act as data and functionality within your application, and 2) we also will integrate with any normal modern API that is available for any other third-party services. One of the things that we’ve done is we’ve pre-integrated with a number of third-party services that make it faster and easier to build a solution, including things like weather data from the national weather service or satellite imagery for mapping applications or the ability to send and receive text messages. Those are third-party services that we’ve already pre-integrated to, but those aren’t the only ones we can integrate to. We have a very open system that allows anyone to integrate with us and we can accommodate integrating any other third-party API on an as-needed basis. We’ve just pre-integrated a bunch of stuff that’s common.
Does ObjectSpectrum offer turn-key private wireless networks?
Yes. This is especially true for applications that have a specific geography. This could be on a farm or in a building or on a campus where the solution is well suited for a private network and the private networks can include things like LoRaWAN as well as private LTE or even in some cases, private WiFi or Bluetooth networks. Obviously, it depends on the application, but when it makes sense, we can and do provide the network and the management of a complete network solution.
There have been prospects in the past that have assumed “If I am using a public network, I’ll have to pay for it, but if I’m using a private network, it should all be free, right?” Nope. Not right at all. Think of the network as one part of your overall solution. If we use a public network, then that public network needs to provide service to you, and they will charge you some type of recurring fee to do that. If we build a private network for you, we still have to provide that service, so there’s some kind of fee whether it’s built into our monthly rate, or the fee associated with the number of devices that you have, but it’s not free. Just because it’s private does not mean there’s no cost to it. Somebody has to actually operate it. Now, typically the cost will be less for a private network than a public network, but in some cases you have to use a public network because there is no other choice.
Does ObjectSpectrum offer support?
Nope, you’re on your own, sucka. Okay, okay – yes, of course we do. As part of us hosting your solution for you, support for you is included within that service contract. If you are licensing our software, support is also provided as part of that licensing contract. And while those options don’t include support to your end customers, end customer support is one of the optional services you can choose (as part of our IoT as a Service offering).
Why use ObjectSpectrum instead of an IoT SaaS company?
ObjectSpectrum is primarily a software engineering company, focused on creating IoT solutions. We are more like a traditional software outsourcing company than a SaaS provider. An IoT SaaS company is primarily looking for a customer that wants to do it themselves and is willing to operate within the constraints of their software. The closer you get to a tool that can be used by non-software engineers (i.e. application designers and developers), the more you will have to play by the rules they have created in their software. Their software will let you take your knowledge of your warehouse, for example, and combine that with their software to connect and monitor this thing and that thing, and that’s great. But by targeting that kind of a user, you are going to be putting constraints around what you can do. And for some people, this may be completely fine. That might be the best choice for them and their situation.
If you are an enterprise customer, and what you need is to collect data from a hundred different sensors in your factory, or GPS trackers on your hundred different pieces of heavy equipment, then an IoT SaaS company could be okay for you because it will let you build a functional application. But the problem is that you are still going to be working within those constraints. To be clear, we are not knocking the idea of you working with an IoT SaaS company. We are just stating what’s different about that type of company and ObjectSpectrum. It’s important for you to understand the differences so that you can make the best choice for your specific situation.
But the dirty little secret of any SaaS company is that if you need to go beyond the scope of capability that they deliver to you, you either a) have no choice because they didn’t provide you with a way to extend it, or b) you now need to bring in the hardcore developers that are necessary to go beyond that set of functionality provided with the software. If you’re trying to build an application that is going to be offered for sale, either as a standalone service or as part of something that you’re selling, you want something that is a lot closer to from-scratch software development. You want something that doesn’t have those constraints; you need something that isn’t designed for a non-technical user. Because you’re going to run into issues with the SaaS products where they simply don’t meet your needs, and then what do you do? So the target audience for this is typically someone who is using it internally and they’ll tell you, “oh no, you can white label it, put your logo on it and offer it to your customers,” and that’s all great. If what you actually need is what they thought you needed, you’re in good shape. But as soon as you cross that line, you’re now into having to bring in the technical people to actually get the job done.
The bottom line is that an IoT SaaS company is not in the business of IoT solutions engineering. It is in the business of licensing a piece of software. ObjectSpectrum is in the business of solutions engineering. Tools like an IoT SaaS company can be a great prototyping tool. Because once you learn how to use their tool, it can be very quick and easy to set up, “okay, we need to monitor these five sensors and we need to test this thing over the next two weeks” and that type of stuff. It can be a great prototyping tool. Unfortunately, with most IoT SaaS companies, it comes with a pretty high price tag just to license it. So that makes it kind of an expensive prototyping tool. That’s not the case for every single one of them (IoT SaaS companies), but it is with a lot of them.
Why use ObjectSpectrum instead of a custom software or an Internet application development firm?
There are three issues here:
- ObjectSpectrum has our own software and tools that were purpose-built to rapidly design, develop and deploy IoT solutions. That is our secret (or not so secret, since we’re putting it on a public website) weapon. If you go to a software outsourcing firm, they are going to use tools, development environments and third-party components and whatnot that they know and that are available to them in the market. They’re not bringing any intellectual property of their own to the table. We’re bringing intellectual property that was purpose-built to accelerate these types of solutions and not only for the purpose of making it go faster, which directly translates into less cost, but also in reducing risk. In the sense that, when we develop a solution, we are using a set of tools and libraries and both in-house developed and third-party stuff that already works together and has already been field-proven and tested. We already know that it’s secure. We already know that it scales. We already know all of this stuff about it, whereas a custom developer has to figure that out about every single aspect of even the tiniest components they create as a part of the solution. In a sense, nobody starts from scratch these days – ‘cause what does “from scratch” mean anyway? But the difference is that we’re starting you five years ahead of where you would be starting without us. Way ahead. Our starting point is 80% of the finish line compared to the 0% starting point of any software outsourcing firm would be starting from.
- They may not have a lot of experience in IoT. Maybe they’ve developed complex games, or maybe they’ve developed complex e-commerce websites. However, the skillset to create applications like those are not the same skillset required to create IoT applications. There can be some overlap, but not necessarily. Do not be fooled by promises made by sales engineers who say, “We can do this, we can do that, we can do IoT.” IoT is very different. It’s a very deep “stack” with many layers – much more so than an e-commerce site. But even if you don’t want to compare them, you can just say that they’re very different. We wouldn’t use Prism (our IoT solution platform) to write a first-person shooter game, for example. And it’s also about expertise. We are specifically and solely focused on IoT, we have deep experience at all levels of the stack, we have strong relationships in the ecosystem (vastly undervalued by some), and we know what it takes to design, develop, and deploy an IoT solution having focused on solely those since 2016.
- Unlike typical custom software development firms, we become our customer’s software partner. That’s a lot of talk in many cases, but for us, it means that we host the application (most of the time; some of our customers host it themselves, and in that case, we support their internal team), provide 24/7 monitoring and support, fix bugs, and develop updates and enhancements. IoT applications, unlike the typical “phone app”, have long lives—years in most cases—and it means a lot to maintain that continuity with the same team that designed and built the application. So we’re in it for the long run.
It ultimately translates into speed, cost, expertise, and low risk.
Concepts and Definitions
What is Business Process Management (BPM)?
Business Process Management (BPM) is a methodology that helps organizations design, implement, monitor, and optimize their business processes. It focuses on improving efficiency, reducing costs, and enabling adaptability in workflows across the entire organization. BPM aims to streamline operations and eliminate bottlenecks in routine tasks. A key component of BPM is automation, with Robotic Process Automation (RPA) being one of the tools used to automate repetitive, rule-based tasks. While BPM covers a wide range of process improvements, RPA is specifically focused on task-level automation.
What is Robotic Process Automation (RPA)?
Robotic Process Automation (RPA) is a technology that automates repetitive, manual tasks typically performed by humans, such as data entry, processing transactions, or generating reports. It allows businesses to improve accuracy and save time by handling routine digital tasks. RPA is an integral part of Business Process Management (BPM), helping streamline individual processes within a larger operational framework. At ObjectSpectrum, we supercharge traditional RPA by integrating IoT, which expands automation into physical tasks. To learn more about how we enhance RPA with IoT, check out our RPA + IoT page.
What’s the difference between traditional RPA and IoT-driven RPA?
Traditional RPA focuses on automating tasks that humans routinely perform on a computer, like data entry, processing forms, or even sending emails. IoT-driven RPA takes it a step further, automating routine physical tasks that your employees or contractors do outside the digital world. Think about real-time monitoring of factory inventory levels, equipment maintenance, or even environmental conditions. We integrate IoT sensors into your existing RPA setup, giving you automation for the physical world, not just the digital one. For more information, check out our RPA + IoT page.
What kinds of physical tasks can be automated with RPA + IoT?
There’s practically no limit. Some examples:
- Inventory Monitoring: Keep track of chemicals, raw materials, fuel, and more—automatically.
- Equipment Inspections: Check the status of motors, pumps, HVAC systems, and fire extinguishers without sending a human.
- Environmental Monitoring: Measure water levels in rivers, air quality in facilities, or temperature conditions in storage rooms.
If your business involves routine checks, inspections, or monitoring, IoT can automate it. You’ll save time, reduce labor costs, and eliminate human error. For more information, check out our RPA + IoT page.
What is Industrial IoT?
IIoT is typically about IoT technologies that are applied in industrial environments. It is differentiated from consumer or commercial IoT applications in the sense that IIoT tends to be more ruggedized and suitable for an industrial environment. The software and the components that go into building the software are very similar, but the industrial IoT’s difference is usually about the physical devices, the sensors that are used, and the functionality of the software.
What is AIoT?
This is a term that you will see spring up here and there, but it is the combination of AI (which is really Machine Learning) and IoT. It’s kind of a marketing term. It doesn’t imply any particular technology. It’s just about using Machine Learning as part of an IoT application.
What is Declarative Development and how can it shorten development time?
Declarative means you are not writing “functional” or “procedural” code to do something. Instead, you are declaring what you want to happen.
The main example of a declarative approach within Prism is Prism View. For example, instead of writing code that tells the browser how to draw a bar graph, the UI/UX person that is developing the UI part of the solution declares how they want that bar graph to appear. They are saying, “I want a bar graph, I want it to be here, I want it to be this size, I want it to use these colors, I want it to have these labels, I want it to pull from this data.” That’s what declarative programming is. You are declaring what you want to happen, you are not writing software to make it happen. The advantage is that it’s faster to develop, it’s less error-prone, and it’s easier to maintain over the life-cycle of the application.
Another example is our Binary Schema module, used to decode packed binary data payloads, typically received from sensor nodes. While it runs in Prism Core and Edge, which are not declarative environments, the process of building a payload decoder with the Binary Schema module is itself declarative. So instead of writing code that procedurally extracts data from the binary payload (which can quickly turn into some real spaghetti code), the developer simply declares the desired result: data in the form of meaningful named properties. And as with Prism View, this approach is faster to develop, less error-prone, and much easier to maintain and modify.
What is a Camera as a Sensor?
Camera as a Sensor is when you use video input from a camera (which could be visible spectrum or it could be outside the visible spectrum, such as an infrared camera), and the purpose of the camera is not to send a live video stream back to the application, but instead to capture the video feed, use some type of edge computing (often machine learning) to interpret the information that is being captured by the camera, and then return small bits of sensor data instead of sending the whole video feed. For example, a visual spectrum camera is watching a parking lot and we want to know how many empty parking spaces there are in that parking lot. One camera could potentially see the entire parking lot and allow us to quickly count and transmit the number of cars or empty spaces in the parking lot instead of putting a sensor on every single parking space. Another example would be an infrared camera that is pointed at a particular piece of machinery. It could watch for hot spots on that machine and only transmit an alarm if that machine hit a temperature threshold that was set by in the application. Instead of putting a bunch of temperature sensors all over this machine, one infrared camera can detect the temperature at all 73 places on the machine and send an alert when any one of those 73 places gets too hot.
Check out this blog post that goes into greater detail.
What is Sigfox?
Like LoRaWAN, it is also a long-range, low-power, low-bandwidth wireless communication technology. It is available worldwide, with some countries having outdoor coverage and some cities having indoor coverage. It’s always provided by a Sigfox public service provider. So, unlike LoRaWAN, you can’t have a private Sigfox network, but in other ways they are somewhat similar in the sense that they are designed to send small amounts of information over long distances. Sigfox is often found in remote sensing applications, which include things like meter reading, agricultural applications, and tracking applications.
What is a “gateway”?
A device that has the only (or primary) job of routing data from one technology to another. So, for example, a LoRaWAN gateway is one that sends and receives messages over the LoRa wireless technology and then relays that information back to the cloud, possibly using cellular technology, or maybe just a direct connection to the Internet. And some gateways can have additional functionality beyond that, like computer resources for edge computing, but that’s the basic gist of what a gateway does—it translates data between different networking technologies.
What is “device management”?
Device management is the ability to add a device to whatever kind of network or connectivity that device is using to communicate. That process is usually called provisioning. You are provisioning a device on a network. That could be a lot of different things, but one example of that would be provisioning a device on a cellular network. That is how you set that device up so that it can connect to and send data over the cellular network. That’s the first part of it. The second part of it is when you have large quantities of these devices, you need some way to manage those devices. You need some way to detect that a device is not working anymore. If it’s battery-operated, you have to check the battery’s charge to make sure it’s not running out. And if the devices can support “firmware updates over the air” (FUOTA), you need a way to manage that. These are all things that are typically done as a part of device management. It doesn’t necessarily have anything to do with the device, nor with the application – it has to do with how you add, monitor, troubleshoot, replace, and ultimately remove the physical devices from the communications network they’re communicating on. And, depending on the particular requirements, Prism can either include device management as part of the application or it can integrate with third-party device management platforms when appropriate.
What is an IoT “platform”?
Unfortunately, the term “platform” is used in a lot of different ways to mean a lot of different things. It’s unfortunate because it’s hard to really nail down what it means in any specific instance. At a very generic level, a “platform” is something designed to make it faster, easier, lower cost and lower risk to build and manage something. Some of the other ways that the word “platform” is used is to describe a particular family of hardware that comes with development tools and libraries and perhaps some type of provisioning system, and that might be referred to as a “platform” because it’s the building blocks and the scaffolding, if you will, that you would use to build a device.
You can also have “platforms” where their focus is more about device management, so they don’t really have anything to do with the devices themselves, they don’t really have anything to do with the application, but they have to do with how you provision and manage thousands or hundreds of thousands of devices. And as you work your way up the stack, the word “platform” has been used for what Prism is, which is a set of tools and an operating environment that is built around the idea of using it to build custom applications. And sometimes software like Prism is called an “application platform” or even an “application enablement platform.”
What is 5G? What benefits does it provide?
5G is a collection of technologies that make up the next generation of cellular technology. The two big selling points of 5G are: 1) much higher bandwidth than is typically possible with current 4G technology, and 2) lower latency than is typically seen with 4G technology. As with so many things, having 5G doesn’t necessarily guarantee that you’ll have higher bandwidth than any possible 4G tech, but in general, the technology is built around the idea of being able to provide higher bandwidth and lower latency. So, if your application specifically requires either very high wireless bandwidth or very low latency, then 5G might be a good choice. If it doesn’t require either or both of those, then there may not really be an advantage to you to use 5G. The 4G cellular network is not going away any time soon. 5G is the next generation and those are the two things it’s designed to do. If you care about those things, then 5G might be worth looking at. But if you don’t care about those things, then 5G may not matter to you at all.
Also, you may see NB-IoT and Cat-M1 technologies talked about as being part of 5G. While they are considered to be part of 5G, they actually did exist as part of 4G as well. Sometimes people will talk about low-bandwidth/low-power being a feature of 5G, but they are really talking about NB-IoT or Cat-M1.
What is NB-IoT and Cat-M1? What’s the difference?
These are two different cellular technologies that run on the cellular network. They’re both designed to be used for low-powered devices that have relatively low bandwidth requirements. So, in a way, they are competing standards, but in most places today you will find support for either or both. And they do have some slight differences in their capability that might make you lean one way or the other, but if you were going to build a cellular-based IoT device that didn’t need high bandwidth, then one of those two technologies would probably be the way to go.
What is BLE?
Bluetooth Low Energy (BLE) is a relatively short-range technology that is universal (works on the same frequency anywhere in the world), very accessible (every smart phone has BLE capability), and it is also for transmitting relatively small amounts of data. It is not the same as Bluetooth. Bluetooth Low Energy is not Bluetooth, but of course they are often easily confused. They are related to each other, but Bluetooth has enough bandwidth that you can send high quality audio over it to your earbuds. BLE is designed for low-power devices with small amounts of data. For certain applications where you don’t care that much about range, and/or you want to be able to connect directly to an end user’s smartphone (one example of this is cloudless IoT applications), then BLE is often a good choice because it has that universal accessibility combined with the ultra-low power capability that no other technology really has, meaning you can build battery-powered BLE devices that last for years on a battery. Another place that we would tend to see BLE used is as a secondary wireless technology used on a device that may have a LoRaWAN or a cellular radio on it as its primary communication link, using the BLE wireless device as a way to configure or provision the device (because it can be done using any smartphone). It’s not super common, but it does happen.
What is LoRaWAN?
LoRa stands for “long range,” so it the word literally means “long-range wide area network.” It is a low-power WAN modulation technique that uses license-free frequency bands to transmit small amounts of data – either over long distances (ten miles or more) or through obstructions like buildings, typically being able to penetrate several concrete walls. It’s used in a lot of applications, including agriculture, smart buildings, smart cities, where you need either the long-range or the deep building penetration capability to wirelessly collect data from sensors and/or wirelessly send commands to actuators. It is often used in applications that need to be very low power, like battery-powered devices that last five years or more on a battery, or energy-harvested devices, like devices that run on solar power virtually forever. It’s a wireless technology that can either be operated on a private network or on any one of a number of public networks that provide LoRaWAN connectivity for a monthly fee. LoRaWAN is one of the wireless technologies that we use at ObjectSpectrum, and often includes network management services for private LoRaWAN customer networks as part of the solution. We are also member of the LoRa Alliance, which certifies LoRaWAN devices.
What is a “time series database”? How is it different from a “regular” database?
A time series database is specifically about being able to store the same information over time and then being able to quickly aggregate that information. This is very common in IoT because typically you have data coming in from all the different sensors, and those sensors are reporting that data, usually on some type of interval (maybe it’s every minute or every hour or whatever the case is), and it’s the same information each time but it has a different time stamp. So the time series database – you could technically store a time series in any kind of database – but that is specifically designed to be very efficient at storing the same information over and over again with a different time stamp on it. It’s very efficient at being able to aggregate that data so you can say well, I have rainfall data from every ten minutes over the last week but I want to know quickly how much rainfall we had in the last week. A time series database is very good at aggregating that and giving us the count – the rainfall data for the week as opposed to the data from hundreds of different samples. A time series database is purpose-built and very common in IoT because IoT by its very nature is all about collecting data over time and reporting the aggregated data to the user. Other database technologies just don’t do this very efficiently. A time series database, because it is such a common requirement for IoT applications, is one of the capabilities that’s built into Prism.
What is a “microservice environment”? What makes it better for IoT?
It is what Prism Core and Prism Edge are built on. It uses a software development model where instead of writing one giant program that performs a set of functions, it breaks each of those functions down into its own individual service. So, we didn’t invent it, but it’s a way of writing software where you’re not dealing with a big monolithic piece of software, you’re dealing with a whole bunch of separate services that all do one very specific thing. The nature of the application that is built on those services is it makes use of those services to do all of those things it needs to do. The reason it’s good for IoT is that IoT tends to need to be very scalable and tends to need to be operating 24/7 and a microservice environment is very good at meeting those two requirements. Because since you don’t have a giant monolithic piece of software, and you have tiny little pieces of software, it’s very easy to scale that. You literally just add more servers and you’ve scaled up your application.
The other thing is that for the same reason, it is very good at something that’s running 24/7 (or “high availability systems”) because you’re not dependent on any one server continuing to run. If the server fails, you did lose some portion of your capacity, but those microservices are able to run on any one of the other twenty servers that you have. So for both of those points, microservices are extremely good at high availability and massive scale. That’s why we chose it. A third reason is that it makes it easier to do maintenance and to update complex applications because you can go in and work on a specific microservice without really risking breaking other functionality because they’re all independent of each other.
In the Prism Edge environment, the individual microservice is the thing that is updated when you’re doing a software update to the Edge. So, it’s very precise, it’s very low bandwidth, you make one change to one microservice and that’s the only thing that’s sent out to the Edge device. You’re not having to send a very large file with an entirely new copy of the application you’re doing just a pinpoint update on only that microservice that you’re changing.
What is “edge computing” and when is it needed?
Think about the “edge” as being the physical location of wherever the IoT solution is happening remotely. So, it’s not where the user is. It’s where the remote thing is. For example, if you are monitoring a generator in a factory, the “edge” is where that generator is in that factory. So, when you hear “edge computing,” it’s basically saying “instead of the computing going on in the cloud somewhere, the computing is going on at the site of the thing.” The reason you might want to do this is because: a) you may not have time for the two-way communications to make the round-trip to the cloud and back (called “latency”), b) it might be in a remote spot where a connection to the intent is spotty or non-existent, and/or c) the nature of the remote sensing can benefit from doing some of the work locally to reduce the bandwidth needed between there and the cloud. It moves the computing to the place its most needed. That speeds it up, and that means it doesn’t have to be connected to the internet, or can use less bandwidth, to function.
The “edge” could be literally on the device itself, or it could be some type of a local computing appliance or other computer that is located near or within the place where the data is being collected.
Typically, edge computing is used when you need to make very quick decisions – when you don’t have time to send measurement data to the cloud, have the cloud to the analytics, and then send the command back to the device. That is called latency. Even if that process is very, very quick, there is a fraction of a second that it takes to send those messages back and forth. And in certain applications you have to make those decisions very quickly.
Another case for edge computing would be cases where you had very limited bandwidth. For example, if you had some type of a sensor – like a camera that was collecting a lot of data for video that requires high bandwidth – but you were using the edge computing to count the cars that were in the field of view of the camera. And all you cared about was the number of cars. That’s a case of edge computing taking very high bandwidth information – the video – and turning it into very low bandwidth by just relaying the message, “there are seven cars now.”
The last of the big three reasons to use edge computing is if you need the system to be able to operate without being connected to the cloud. This is less being about “cloud-optional” and more about being fault-tolerant. If you have a system that you can’t afford not to work if your internet connection goes down, then edge computing is one solution for that. Where it can make local decisions, or continue to collect data until the internet connection comes back up again.
Those are typically the big three: 1) to solve latency (need it to be fast), 2) when you have limited bandwidth (does the high bandwidth stuff locally and converts it into low bandwidth information), or 3) when you have spotty internet connectivity at the site where it’s collecting data.
What is a “digital twin?”
Effectively, it’s a computer model of a physical thing. That model is not like taking a picture of the physical thing, it’s a set of business logic and rules that define how that thing operates. This is so that you can simulate the operation of that thing without actually doing it in the real world. It’s like a virtualized version of a physical thing. The idea is that you are able to maintain that model – the virtual model, the twin – in such a way that it reflects the physical thing that it’s mapped to. So, it’s one of those things that people tend to talk about, but it’s not something that you will find widely deployed because it’s incredibly complicated and expensive to do. The more elaborate the physical thing is, the more complicated and expensive it is to build and maintain a digital twin.
So, if you have a fairly simple physical thing – like let’s say it’s a generator – and you’ve got several sensors on that generator, you could build a digital twin of that generator that will allow you to simulate certain aspects of that generator so you can do things like – what happens if I run it at 110% of its capacity for a year? Probably don’t want to do that with your real generator, but you could do it with a digital twin and the theory is that if the computer model is accurate enough, then you will usually get data out of the model that is representative and fairly accurate of what would happen in the real world. That’s the basic idea of a digital twin.
It can get more complex than that, though, because they can also simulate what would happen if there were physical modifications made to the physical thing. In that case, the modifications to the physical item would also have those same modifications made in the computer to the digital twin. Then you could have an entire fleet of physical generators, all with their own modifications, and then a digital twin for each of those generators in the computer, where each digital twin is an exact duplicate of its specific generator and you can just make the modifications in the computer to each one before you make that modification to the physical generator. Here are some real-world examples.
What is “cloudless IoT?”
It is an IoT solution that either does not connect to a cloud service of any kind or does not need a cloud service in order to function. So, typically the places you would find cloudless IoT of the first kind are going to be applications where the connectivity between the IoT devices and the user are going to be over a local technology, like Bluetooth, where the functionality is usually running on a phone and the IoT devices are connected to that phone using Bluetooth. You’ll find that sometimes in consumer IoT where you’ll have a phone app that controls a light bulb, for example. It’s cloudless in the sense that there is no need for it to go to and return from the cloud in order to turn on your lightbulb. Although, bizarrely, there are many examples of apps that turn on light bulbs that actually do have to make a roundtrip to the cloud in order to perform that function. Most IoT solutions that we build are not “cloudless”, because they involve interfacing with remote things and accessing them over the Internet.
What is an “application template”?
Templates are basically pre-built modules that are largely complete, but still allow for significant customizations. This is one of the ways we can speed up development of applications. If your application needs user management or device management or needs a visualization that involves markers on a map – those are templates that we have already built, having already done 80% of the work for that function. And then from there, we can incorporate it into your application and customize it for your specific requirements.
Templates are also a secret weapon for us, in the sense that they’re not shrink-wrapped modules that can’t be customized or modified to a particular application need, they’re almost like the structure and the components and the building blocks that have all been pre-integrated together for the common kinds of functionality. So it means that we can very quickly and take one of those templates and use as the starting point for that functionality, while still allowing for a high degree of customization to make it work for the needs of a specific application.
What are the advantages of no-code development environments?
There is some confusion around what people mean when they use the term “no-code” (and also “low-code”). The idea, theoretically, behind no-code is that you do not need to be a programmer to use it. The problem with that concept is that some of the things that you are doing within a no-code environment actually does involve defining logic. But you’re typically doing that through some kind of drag-and-drop interface. So instead of writing a piece of code that defines the logic, you’re drawing something like a diagram on the screen, and that’s what defines the logic. So, the question there is, “haven’t we just given you a programming tool that just gives you a different way of programming?” We liken this to a WYSIWYG HTML tool like Dreamweaver used to be. I still had to tell it I want this option field to be a radio button. I want it to have these values, I want these values to mean these things, and I want the submit button to go here and write this to the database. I didn’t have to code it myself with a programming language, per se, but I still was programming in a different way. That is typically what people mean when they call something “no-code.” They mean something you can program through a drag-and-drop interface. And it theoretically does not require any programming skills.
Low-code is kind of a hybrid, where it requires some programming skills, but much of it can theoretically be done by someone without programming skills. So, the problem is that different people in different companies will describe their tools as no-code or low-code without a consistent definition of those terms across different companies and even people within those companies. The bottom line is that – in both cases – this category of low-code and no-code, which typically go together in discussions (which reinforces the fact that there is a lot of confusion between the two terms), they tend to be very highly opinionated environments. Which means that – whatever you’re building – you are going to be operating under the limitations that someone thought you might need when they built their platform. So, if you want to put a chart on the page, then you pick a chart from one of their drop-down meus, they put a chart on the page and they give you three things you can change like the color and the title and that’s it. Highly opinionated just means there are a lot of constraints because the closer you get to no-code, the less flexible it becomes. The other limitation is that – if you want to do something that the tool has not anticipated that you want to do – you probably just can’t do it. You probably have to wait until the vendor of that tool provides it because you have no ability to extend it yourself. Now, some low-code environments will give you a way to extend it, but it’s kind of weird because – if you bought the thing to use it without being a programmer – how are you expected to be a programmer when you get to the things that require a programmer?
They tend to be more suitable for simpler applications and they tend to make for a nice demo. They’ll show you how quickly you can make a page with some charts and gauges on it, how to hook it up to a data source and have a running application. But it’s typically a rather simple application that doesn’t involve anything that’s too far outside of what the capabilities are of the tool and isn’t particularly complex when it comes to the logic that it encapsulates.
The potential benefit to those types of tools is that they can sometimes be used to quickly prototype something. These are often great for prototyping a demo to show your idea’s potential to an investor or your board, for example. So the advantage of it being highly opinionated is that they tend to automatically make a lot of assumptions for you. So you go in and define a data source and the data is coming from wherever and when you drop your chart on the page, it’s usually smart enough to assume that the data is coming from that data source that you specified and it automatically hooks it up for you. As a result of it making a lot of assumptions for you, for doing a quick prototype, it can be useful. But they tend to break down when you go too far beyond simple solutions and basic prototypes and they don’t provide much flexibility when it comes to look and feel and user experience.
Also, just because a no-code environment doesn’t require true programming skills does not mean it doesn’t have a learning curve. The people that do those videos that show them building an app in three minutes? Yeah, they’ve been doing it for years, on that specific platform. It looks super easy because the people who are showing you that have been doing it for a while. They may even be the same people that developed it.
Should I use AI or ML in my solution?
Machine learning (ML) is a branch of artificial intelligence (AI) and computer science which focuses on the use of data and algorithms to imitate the way that humans learn, gradually improving its accuracy. AI, or artificial intelligence, is a term that defines a broad category of intelligence – much of which is still highly experimental, or even still solely theoretical. But one component of AI is ML, or machine learning, which is a mature technology that is already in use in thousands of applications across hundreds of industries. And is something that you would often find as part of an IoT solution. As to whether you should use it or not, the real answer is “it depends.” Machine Learning is not a magic bullet or ingredient. Machine learning is a technology like any other that, in certain applications, can add a tremendous amount of value to the solution. And in other cases, it has no place in the solution. We have experience using machine learning. We will look at machine learning as a possible element of your solution when it makes sense to do so. But we have no vested interest in whether we include ML in your solution or not.
What is an “ecosystem” as it relates to IoT?
The ecosystem is the whole collection of companies that are part of the stack that makes up an IoT solution. Very rarely will you be able to create an IoT solution on an island in isolation, in a vacuum. Because the nature of IoT is that it makes use of components that typically come from a lot of different places. So that would include companies that make sensors, radios, network providers that are providing connectivity, cloud service providers, application developers, and many other components. So, the ecosystem is this collection of manufacturers and service providers that all play a role in the different components that make up an IoT solution.
What is IoT as a Service?
It’s a managed service that’s customized to your needs that can provide everything necessary to turn-key your IoT solution, including things like end-user support and logistics. We can take care of ordering and managing your inventory and shipping devices to your end-users. The customer can do as much as they want to do, and we’ll do the rest – whatever “the rest” is (0%, 100%, or anywhere in between).
What is IoT?
IoT, in general, is taking the ability to see what’s happening remotely through sensors using modern internet technologies. The big thing that makes IoT IoT is that – in the past – this kind of thing would have been called telemetry or machine-to-machine (M2M) communications. The difference is that those solutions (which have been around for a really long time) is that IoT leverages technology that was originally developed for smartphones. And the reason that is important is that the sheer volume of the smartphone market is what effectively paid for the miniaturization and cost reduction of these technologies. Twenty years ago, if you had wanted to put some sensors on a remote piece of oil well equipment, you could absolutely do it but it would have cost you tens of thousands of dollars. Because the sensors were expensive, the computers were expensive, the connectivity was expensive, everything was expensive. But the fact that they are producing billions of cell phones every year, and the fact that we now have the miniaturization – I mean, think about it. Your phone has a GPS in it, right? Remember how big a GPS used to be? It was its own separate thing! It’s all done on a tiny little chip now. And all the other sensors in your cell phone and even the whole wireless component of it – all of this stuff we use is all from cell phones.
That market is so large that it drove the prices down and the size of it and the power requirements of it down. So, what IoT is doing is taking advantage of all of that and it’s saying, “Hey, no longer do we have to go out and spend $3,000 on a sensor that can communicate wirelessly and tell us what the humidity is in this place. We can now do that for $30.” So that is the big deal. From a “what makes IoT different from telemetry or machine-to-machine communications that have been around for decades” perspective.
From the standpoint of “why does all this matter,” having remote visibility to things in real-time lets you make better decisions. It really is as simple as that. If you are a manufacturer of HVAC equipment, knowing that the pressure of the coolant in that system is 20% low, and knowing that today is going to give you the ability to make better decisions and provide better service to your customers, make the equipment last longer, etc. as compared to not knowing that information for six months until you go out and inspect that piece of equipment on its scheduled maintenance call. That’s really the bottom line: from a business standpoint, it gives you remote visibility to actionable data in real-time to enable you to make better business decisions. And because of this cell phone-driven path to low power, tiny, low-cost sensors and cheap wireless communication, suddenly this technology is in reach of almost any company as opposed to only the EXXONs of the world.
These are the salient points – the gospel, if you will – of IoT.
What Is an IoT Proof of Concept (PoC)?
A very small-scale deployment where you’re focusing on the key functionality of the desired solution. We strip away everything that is not necessary beyond the key functionality that you’re trying to evaluate. For example, if you’re trying to determine whether or not measuring atmospheric pressure is going to give you useful, actionable data for your factory, then the first thing we would do is create a minimalist solution – almost a laboratory test, in a way – that we can put some barometric pressure sensors into your factory, collect that data in a way that can determine whether it’s going to be useful or not before we spend any time and money building a whole application around that process. It’s a minimalist implementation that strips away everything but the core or key functional aspects, and to some extent it could be deployed in a very small scope among data testers or in maybe a couple of test environments where the idea is to basically test whether or not something will work and give you the actual data that you’re looking for.
The other thing about a proof of concept is that you will almost always learn things from the POC that will influence the requirements and objectives of the full solution development. So, it’s something that we often recommend as a way to test out a concept before you commit to the full project. And of course, this is on a case-by-case basis. Sometimes it may not be necessary and other times it may not be feasible to do it.
What makes up an IoT solution?
This is where you get into that whole “stack.” Typically, you think about it from the bottom up. You’ve got: the thing – what you want to remotely monitor or control – what is that device that does that monitoring or control, what kind of hardware is it built with, what kind of software is that device running, how does that device now communicate to a network that allows it to send its data that is collected to somewhere else. How does that network connect to the application, which is now collecting and storing data from all of those devices that are deployed? How do analytics and machine learning apply to that data? How do users interact with that information (the application layer with visualization and user input)? How do you store that information long-term so that you can analyze the historical information? That is an IoT solution. It’s the hardware, it’s the firmware, it’s the network communication, it’s the application, the database, the analytics, it’s the user interface, data visualization, and tying all of that together into an end-to-end solution.
How is IoT different from telemetry or M2M (machine-to-machine)?
In a sentence, it is different because it is the beneficiary of the proliferation of mobile devices, etc. and it has driven the price down and the accessibility up. And that’s why it’s a revolution now.
And by the way, when the internet became public knowledge – the vast majority of people had not heard of the internet until 1993 – but it existed since 1969. The point is that the ability to do remote monitoring has existed for decades. The ability for it to be accessible – both from a cost and widespread use of technology – that’s the revolution. The inflection point in the nineties of what made the internet what it is today, was a culmination of different trends that – over the years – had made it more accessible. Between 1969 and 1993, it was used primarily by the government and the military because they were the only ones who could afford it, and by universities who were funded to advance it. So we’re seeing the same kind of thing happen here with IoT, which many companies/industries – particularly large companies/industries have been using different kinds of telemetry technology for decades, but until IoT, it really hasn’t been accessible to the masses.
What are “things” in the Internet of Things?
It’s typically a piece of equipment or object that you are trying to remotely monitor. It could be an HVAC system or it could be a field full of corn plants. It is the thing that you want to remotely monitor or manage. A thermostat in the building, part of the building itself, it could be a truck, it could be a corn crop, it could be a cow. Most IoT is one-way – we’re collecting data and making use of that data. But of course, you can also send commands downstream and in some cases, remotely control those things. Soil moisture probes and hyperlocal weather stations are good one-way examples, and remotely monitoring pipe pressure and then remotely controlling the shut-off of a pipe is a good two-way example. The “thing” is any of those things.
And by the way, the reason the term “Internet of Things” was coined, is that we typically think of the endpoints of the Internet as being people – “I am on my computer/phone using the internet.” The internet of things is that the endpoint is not a person. It’s a thing.
General Information
What is Business Process Management (BPM)?
Business Process Management (BPM) is a methodology that helps organizations design, implement, monitor, and optimize their business processes. It focuses on improving efficiency, reducing costs, and enabling adaptability in workflows across the entire organization. BPM aims to streamline operations and eliminate bottlenecks in routine tasks. A key component of BPM is automation, with Robotic Process Automation (RPA) being one of the tools used to automate repetitive, rule-based tasks. While BPM covers a wide range of process improvements, RPA is specifically focused on task-level automation.
What is Robotic Process Automation (RPA)?
Robotic Process Automation (RPA) is a technology that automates repetitive, manual tasks typically performed by humans, such as data entry, processing transactions, or generating reports. It allows businesses to improve accuracy and save time by handling routine digital tasks. RPA is an integral part of Business Process Management (BPM), helping streamline individual processes within a larger operational framework. At ObjectSpectrum, we supercharge traditional RPA by integrating IoT, which expands automation into physical tasks. To learn more about how we enhance RPA with IoT, check out our RPA + IoT page.
What kinds of physical tasks can be automated with RPA + IoT?
There’s practically no limit. Some examples:
- Inventory Monitoring: Keep track of chemicals, raw materials, fuel, and more—automatically.
- Equipment Inspections: Check the status of motors, pumps, HVAC systems, and fire extinguishers without sending a human.
- Environmental Monitoring: Measure water levels in rivers, air quality in facilities, or temperature conditions in storage rooms.
If your business involves routine checks, inspections, or monitoring, IoT can automate it. You’ll save time, reduce labor costs, and eliminate human error. For more information, check out our RPA + IoT page.
What is Industrial IoT?
IIoT is typically about IoT technologies that are applied in industrial environments. It is differentiated from consumer or commercial IoT applications in the sense that IIoT tends to be more ruggedized and suitable for an industrial environment. The software and the components that go into building the software are very similar, but the industrial IoT’s difference is usually about the physical devices, the sensors that are used, and the functionality of the software.
What is AIoT?
This is a term that you will see spring up here and there, but it is the combination of AI (which is really Machine Learning) and IoT. It’s kind of a marketing term. It doesn’t imply any particular technology. It’s just about using Machine Learning as part of an IoT application.
What is a Camera as a Sensor?
Camera as a Sensor is when you use video input from a camera (which could be visible spectrum or it could be outside the visible spectrum, such as an infrared camera), and the purpose of the camera is not to send a live video stream back to the application, but instead to capture the video feed, use some type of edge computing (often machine learning) to interpret the information that is being captured by the camera, and then return small bits of sensor data instead of sending the whole video feed. For example, a visual spectrum camera is watching a parking lot and we want to know how many empty parking spaces there are in that parking lot. One camera could potentially see the entire parking lot and allow us to quickly count and transmit the number of cars or empty spaces in the parking lot instead of putting a sensor on every single parking space. Another example would be an infrared camera that is pointed at a particular piece of machinery. It could watch for hot spots on that machine and only transmit an alarm if that machine hit a temperature threshold that was set by in the application. Instead of putting a bunch of temperature sensors all over this machine, one infrared camera can detect the temperature at all 73 places on the machine and send an alert when any one of those 73 places gets too hot.
Check out this blog post that goes into greater detail.
What is Sigfox?
Like LoRaWAN, it is also a long-range, low-power, low-bandwidth wireless communication technology. It is available worldwide, with some countries having outdoor coverage and some cities having indoor coverage. It’s always provided by a Sigfox public service provider. So, unlike LoRaWAN, you can’t have a private Sigfox network, but in other ways they are somewhat similar in the sense that they are designed to send small amounts of information over long distances. Sigfox is often found in remote sensing applications, which include things like meter reading, agricultural applications, and tracking applications.
What web browsers and mobile devices does ObjectSpectrum support?
All modern browsers and mobile devices.
What third-party sensors and devices does ObjectSpectrum support?
ObjectSpectrum supports just about any third-party sensor and device. We have the ability to rapidly integrate new devices. We aren’t limited by any particular list or kind of sensor or device. We figure out what the best solution is for what you’re trying to do, and we are completely agnostic when it comes to the device or any other technology it uses. We can integrate devices from different manufacturers with different technologies so that we can use the best in class for your specific solution’s needs. As a general rule, we try to use off-the-shelf sensors and devices whenever possible, but will work with our partners to develop custom hardware when that’s needed.
What wireless standard is best?
Well, “best” for your solution is different than “best” for someone else’s. And ObjectSpectrum is not tied to any particular wireless or connectivity standard of any kind. We regularly use a number of different technologies, and that is part of the design phase of any solution – to determine what the right technologies are for a given solution. Of course, that’s true no matter what technology we’re talking about (not just the wireless standard). Tracking ships at sea will necessitate a very different wireless technology than something that needs to keep track of pallets in a warehouse. It just depends, but we are not tied to any particular technology.
What is a “gateway”?
A device that has the only (or primary) job of routing data from one technology to another. So, for example, a LoRaWAN gateway is one that sends and receives messages over the LoRa wireless technology and then relays that information back to the cloud, possibly using cellular technology, or maybe just a direct connection to the Internet. And some gateways can have additional functionality beyond that, like computer resources for edge computing, but that’s the basic gist of what a gateway does—it translates data between different networking technologies.
What is “device management”?
Device management is the ability to add a device to whatever kind of network or connectivity that device is using to communicate. That process is usually called provisioning. You are provisioning a device on a network. That could be a lot of different things, but one example of that would be provisioning a device on a cellular network. That is how you set that device up so that it can connect to and send data over the cellular network. That’s the first part of it. The second part of it is when you have large quantities of these devices, you need some way to manage those devices. You need some way to detect that a device is not working anymore. If it’s battery-operated, you have to check the battery’s charge to make sure it’s not running out. And if the devices can support “firmware updates over the air” (FUOTA), you need a way to manage that. These are all things that are typically done as a part of device management. It doesn’t necessarily have anything to do with the device, nor with the application – it has to do with how you add, monitor, troubleshoot, replace, and ultimately remove the physical devices from the communications network they’re communicating on. And, depending on the particular requirements, Prism can either include device management as part of the application or it can integrate with third-party device management platforms when appropriate.
What is an IoT “platform”?
Unfortunately, the term “platform” is used in a lot of different ways to mean a lot of different things. It’s unfortunate because it’s hard to really nail down what it means in any specific instance. At a very generic level, a “platform” is something designed to make it faster, easier, lower cost and lower risk to build and manage something. Some of the other ways that the word “platform” is used is to describe a particular family of hardware that comes with development tools and libraries and perhaps some type of provisioning system, and that might be referred to as a “platform” because it’s the building blocks and the scaffolding, if you will, that you would use to build a device.
You can also have “platforms” where their focus is more about device management, so they don’t really have anything to do with the devices themselves, they don’t really have anything to do with the application, but they have to do with how you provision and manage thousands or hundreds of thousands of devices. And as you work your way up the stack, the word “platform” has been used for what Prism is, which is a set of tools and an operating environment that is built around the idea of using it to build custom applications. And sometimes software like Prism is called an “application platform” or even an “application enablement platform.”
What is 5G? What benefits does it provide?
5G is a collection of technologies that make up the next generation of cellular technology. The two big selling points of 5G are: 1) much higher bandwidth than is typically possible with current 4G technology, and 2) lower latency than is typically seen with 4G technology. As with so many things, having 5G doesn’t necessarily guarantee that you’ll have higher bandwidth than any possible 4G tech, but in general, the technology is built around the idea of being able to provide higher bandwidth and lower latency. So, if your application specifically requires either very high wireless bandwidth or very low latency, then 5G might be a good choice. If it doesn’t require either or both of those, then there may not really be an advantage to you to use 5G. The 4G cellular network is not going away any time soon. 5G is the next generation and those are the two things it’s designed to do. If you care about those things, then 5G might be worth looking at. But if you don’t care about those things, then 5G may not matter to you at all.
Also, you may see NB-IoT and Cat-M1 technologies talked about as being part of 5G. While they are considered to be part of 5G, they actually did exist as part of 4G as well. Sometimes people will talk about low-bandwidth/low-power being a feature of 5G, but they are really talking about NB-IoT or Cat-M1.
What is NB-IoT and Cat-M1? What’s the difference?
These are two different cellular technologies that run on the cellular network. They’re both designed to be used for low-powered devices that have relatively low bandwidth requirements. So, in a way, they are competing standards, but in most places today you will find support for either or both. And they do have some slight differences in their capability that might make you lean one way or the other, but if you were going to build a cellular-based IoT device that didn’t need high bandwidth, then one of those two technologies would probably be the way to go.
What is a “time series database”? How is it different from a “regular” database?
A time series database is specifically about being able to store the same information over time and then being able to quickly aggregate that information. This is very common in IoT because typically you have data coming in from all the different sensors, and those sensors are reporting that data, usually on some type of interval (maybe it’s every minute or every hour or whatever the case is), and it’s the same information each time but it has a different time stamp. So the time series database – you could technically store a time series in any kind of database – but that is specifically designed to be very efficient at storing the same information over and over again with a different time stamp on it. It’s very efficient at being able to aggregate that data so you can say well, I have rainfall data from every ten minutes over the last week but I want to know quickly how much rainfall we had in the last week. A time series database is very good at aggregating that and giving us the count – the rainfall data for the week as opposed to the data from hundreds of different samples. A time series database is purpose-built and very common in IoT because IoT by its very nature is all about collecting data over time and reporting the aggregated data to the user. Other database technologies just don’t do this very efficiently. A time series database, because it is such a common requirement for IoT applications, is one of the capabilities that’s built into Prism.
What is a “microservice environment”? What makes it better for IoT?
It is what Prism Core and Prism Edge are built on. It uses a software development model where instead of writing one giant program that performs a set of functions, it breaks each of those functions down into its own individual service. So, we didn’t invent it, but it’s a way of writing software where you’re not dealing with a big monolithic piece of software, you’re dealing with a whole bunch of separate services that all do one very specific thing. The nature of the application that is built on those services is it makes use of those services to do all of those things it needs to do. The reason it’s good for IoT is that IoT tends to need to be very scalable and tends to need to be operating 24/7 and a microservice environment is very good at meeting those two requirements. Because since you don’t have a giant monolithic piece of software, and you have tiny little pieces of software, it’s very easy to scale that. You literally just add more servers and you’ve scaled up your application.
The other thing is that for the same reason, it is very good at something that’s running 24/7 (or “high availability systems”) because you’re not dependent on any one server continuing to run. If the server fails, you did lose some portion of your capacity, but those microservices are able to run on any one of the other twenty servers that you have. So for both of those points, microservices are extremely good at high availability and massive scale. That’s why we chose it. A third reason is that it makes it easier to do maintenance and to update complex applications because you can go in and work on a specific microservice without really risking breaking other functionality because they’re all independent of each other.
In the Prism Edge environment, the individual microservice is the thing that is updated when you’re doing a software update to the Edge. So, it’s very precise, it’s very low bandwidth, you make one change to one microservice and that’s the only thing that’s sent out to the Edge device. You’re not having to send a very large file with an entirely new copy of the application you’re doing just a pinpoint update on only that microservice that you’re changing.
What is “edge computing” and when is it needed?
Think about the “edge” as being the physical location of wherever the IoT solution is happening remotely. So, it’s not where the user is. It’s where the remote thing is. For example, if you are monitoring a generator in a factory, the “edge” is where that generator is in that factory. So, when you hear “edge computing,” it’s basically saying “instead of the computing going on in the cloud somewhere, the computing is going on at the site of the thing.” The reason you might want to do this is because: a) you may not have time for the two-way communications to make the round-trip to the cloud and back (called “latency”), b) it might be in a remote spot where a connection to the intent is spotty or non-existent, and/or c) the nature of the remote sensing can benefit from doing some of the work locally to reduce the bandwidth needed between there and the cloud. It moves the computing to the place its most needed. That speeds it up, and that means it doesn’t have to be connected to the internet, or can use less bandwidth, to function.
The “edge” could be literally on the device itself, or it could be some type of a local computing appliance or other computer that is located near or within the place where the data is being collected.
Typically, edge computing is used when you need to make very quick decisions – when you don’t have time to send measurement data to the cloud, have the cloud to the analytics, and then send the command back to the device. That is called latency. Even if that process is very, very quick, there is a fraction of a second that it takes to send those messages back and forth. And in certain applications you have to make those decisions very quickly.
Another case for edge computing would be cases where you had very limited bandwidth. For example, if you had some type of a sensor – like a camera that was collecting a lot of data for video that requires high bandwidth – but you were using the edge computing to count the cars that were in the field of view of the camera. And all you cared about was the number of cars. That’s a case of edge computing taking very high bandwidth information – the video – and turning it into very low bandwidth by just relaying the message, “there are seven cars now.”
The last of the big three reasons to use edge computing is if you need the system to be able to operate without being connected to the cloud. This is less being about “cloud-optional” and more about being fault-tolerant. If you have a system that you can’t afford not to work if your internet connection goes down, then edge computing is one solution for that. Where it can make local decisions, or continue to collect data until the internet connection comes back up again.
Those are typically the big three: 1) to solve latency (need it to be fast), 2) when you have limited bandwidth (does the high bandwidth stuff locally and converts it into low bandwidth information), or 3) when you have spotty internet connectivity at the site where it’s collecting data.
What is a “digital twin?”
Effectively, it’s a computer model of a physical thing. That model is not like taking a picture of the physical thing, it’s a set of business logic and rules that define how that thing operates. This is so that you can simulate the operation of that thing without actually doing it in the real world. It’s like a virtualized version of a physical thing. The idea is that you are able to maintain that model – the virtual model, the twin – in such a way that it reflects the physical thing that it’s mapped to. So, it’s one of those things that people tend to talk about, but it’s not something that you will find widely deployed because it’s incredibly complicated and expensive to do. The more elaborate the physical thing is, the more complicated and expensive it is to build and maintain a digital twin.
So, if you have a fairly simple physical thing – like let’s say it’s a generator – and you’ve got several sensors on that generator, you could build a digital twin of that generator that will allow you to simulate certain aspects of that generator so you can do things like – what happens if I run it at 110% of its capacity for a year? Probably don’t want to do that with your real generator, but you could do it with a digital twin and the theory is that if the computer model is accurate enough, then you will usually get data out of the model that is representative and fairly accurate of what would happen in the real world. That’s the basic idea of a digital twin.
It can get more complex than that, though, because they can also simulate what would happen if there were physical modifications made to the physical thing. In that case, the modifications to the physical item would also have those same modifications made in the computer to the digital twin. Then you could have an entire fleet of physical generators, all with their own modifications, and then a digital twin for each of those generators in the computer, where each digital twin is an exact duplicate of its specific generator and you can just make the modifications in the computer to each one before you make that modification to the physical generator. Here are some real-world examples.
Is a cloud service always required for an IoT application?
No. There are cases where there is a cloud connection, but the cloud connection is primarily there to collect data for analysis, and the function for the application that it is performing is completely local. That might mean that the application is running entirely on the phone, or it might mean that there’s some local process, computer, or device that’s actually running the application, so it doesn’t need the cloud to operate. It can connect to the cloud if the cloud is available, but it doesn’t rely on the cloud to operate and do its job. It’s an application that can run self-contained if it doesn’t have connectivity to the cloud.
What is “cloudless IoT?”
It is an IoT solution that either does not connect to a cloud service of any kind or does not need a cloud service in order to function. So, typically the places you would find cloudless IoT of the first kind are going to be applications where the connectivity between the IoT devices and the user are going to be over a local technology, like Bluetooth, where the functionality is usually running on a phone and the IoT devices are connected to that phone using Bluetooth. You’ll find that sometimes in consumer IoT where you’ll have a phone app that controls a light bulb, for example. It’s cloudless in the sense that there is no need for it to go to and return from the cloud in order to turn on your lightbulb. Although, bizarrely, there are many examples of apps that turn on light bulbs that actually do have to make a roundtrip to the cloud in order to perform that function. Most IoT solutions that we build are not “cloudless”, because they involve interfacing with remote things and accessing them over the Internet.
What is an “application template”?
Templates are basically pre-built modules that are largely complete, but still allow for significant customizations. This is one of the ways we can speed up development of applications. If your application needs user management or device management or needs a visualization that involves markers on a map – those are templates that we have already built, having already done 80% of the work for that function. And then from there, we can incorporate it into your application and customize it for your specific requirements.
Templates are also a secret weapon for us, in the sense that they’re not shrink-wrapped modules that can’t be customized or modified to a particular application need, they’re almost like the structure and the components and the building blocks that have all been pre-integrated together for the common kinds of functionality. So it means that we can very quickly and take one of those templates and use as the starting point for that functionality, while still allowing for a high degree of customization to make it work for the needs of a specific application.
What are the advantages of no-code development environments?
There is some confusion around what people mean when they use the term “no-code” (and also “low-code”). The idea, theoretically, behind no-code is that you do not need to be a programmer to use it. The problem with that concept is that some of the things that you are doing within a no-code environment actually does involve defining logic. But you’re typically doing that through some kind of drag-and-drop interface. So instead of writing a piece of code that defines the logic, you’re drawing something like a diagram on the screen, and that’s what defines the logic. So, the question there is, “haven’t we just given you a programming tool that just gives you a different way of programming?” We liken this to a WYSIWYG HTML tool like Dreamweaver used to be. I still had to tell it I want this option field to be a radio button. I want it to have these values, I want these values to mean these things, and I want the submit button to go here and write this to the database. I didn’t have to code it myself with a programming language, per se, but I still was programming in a different way. That is typically what people mean when they call something “no-code.” They mean something you can program through a drag-and-drop interface. And it theoretically does not require any programming skills.
Low-code is kind of a hybrid, where it requires some programming skills, but much of it can theoretically be done by someone without programming skills. So, the problem is that different people in different companies will describe their tools as no-code or low-code without a consistent definition of those terms across different companies and even people within those companies. The bottom line is that – in both cases – this category of low-code and no-code, which typically go together in discussions (which reinforces the fact that there is a lot of confusion between the two terms), they tend to be very highly opinionated environments. Which means that – whatever you’re building – you are going to be operating under the limitations that someone thought you might need when they built their platform. So, if you want to put a chart on the page, then you pick a chart from one of their drop-down meus, they put a chart on the page and they give you three things you can change like the color and the title and that’s it. Highly opinionated just means there are a lot of constraints because the closer you get to no-code, the less flexible it becomes. The other limitation is that – if you want to do something that the tool has not anticipated that you want to do – you probably just can’t do it. You probably have to wait until the vendor of that tool provides it because you have no ability to extend it yourself. Now, some low-code environments will give you a way to extend it, but it’s kind of weird because – if you bought the thing to use it without being a programmer – how are you expected to be a programmer when you get to the things that require a programmer?
They tend to be more suitable for simpler applications and they tend to make for a nice demo. They’ll show you how quickly you can make a page with some charts and gauges on it, how to hook it up to a data source and have a running application. But it’s typically a rather simple application that doesn’t involve anything that’s too far outside of what the capabilities are of the tool and isn’t particularly complex when it comes to the logic that it encapsulates.
The potential benefit to those types of tools is that they can sometimes be used to quickly prototype something. These are often great for prototyping a demo to show your idea’s potential to an investor or your board, for example. So the advantage of it being highly opinionated is that they tend to automatically make a lot of assumptions for you. So you go in and define a data source and the data is coming from wherever and when you drop your chart on the page, it’s usually smart enough to assume that the data is coming from that data source that you specified and it automatically hooks it up for you. As a result of it making a lot of assumptions for you, for doing a quick prototype, it can be useful. But they tend to break down when you go too far beyond simple solutions and basic prototypes and they don’t provide much flexibility when it comes to look and feel and user experience.
Also, just because a no-code environment doesn’t require true programming skills does not mean it doesn’t have a learning curve. The people that do those videos that show them building an app in three minutes? Yeah, they’ve been doing it for years, on that specific platform. It looks super easy because the people who are showing you that have been doing it for a while. They may even be the same people that developed it.
What is an “ecosystem” as it relates to IoT?
The ecosystem is the whole collection of companies that are part of the stack that makes up an IoT solution. Very rarely will you be able to create an IoT solution on an island in isolation, in a vacuum. Because the nature of IoT is that it makes use of components that typically come from a lot of different places. So that would include companies that make sensors, radios, network providers that are providing connectivity, cloud service providers, application developers, and many other components. So, the ecosystem is this collection of manufacturers and service providers that all play a role in the different components that make up an IoT solution.
What is IoT as a Service?
It’s a managed service that’s customized to your needs that can provide everything necessary to turn-key your IoT solution, including things like end-user support and logistics. We can take care of ordering and managing your inventory and shipping devices to your end-users. The customer can do as much as they want to do, and we’ll do the rest – whatever “the rest” is (0%, 100%, or anywhere in between).
What is IoT?
IoT, in general, is taking the ability to see what’s happening remotely through sensors using modern internet technologies. The big thing that makes IoT IoT is that – in the past – this kind of thing would have been called telemetry or machine-to-machine (M2M) communications. The difference is that those solutions (which have been around for a really long time) is that IoT leverages technology that was originally developed for smartphones. And the reason that is important is that the sheer volume of the smartphone market is what effectively paid for the miniaturization and cost reduction of these technologies. Twenty years ago, if you had wanted to put some sensors on a remote piece of oil well equipment, you could absolutely do it but it would have cost you tens of thousands of dollars. Because the sensors were expensive, the computers were expensive, the connectivity was expensive, everything was expensive. But the fact that they are producing billions of cell phones every year, and the fact that we now have the miniaturization – I mean, think about it. Your phone has a GPS in it, right? Remember how big a GPS used to be? It was its own separate thing! It’s all done on a tiny little chip now. And all the other sensors in your cell phone and even the whole wireless component of it – all of this stuff we use is all from cell phones.
That market is so large that it drove the prices down and the size of it and the power requirements of it down. So, what IoT is doing is taking advantage of all of that and it’s saying, “Hey, no longer do we have to go out and spend $3,000 on a sensor that can communicate wirelessly and tell us what the humidity is in this place. We can now do that for $30.” So that is the big deal. From a “what makes IoT different from telemetry or machine-to-machine communications that have been around for decades” perspective.
From the standpoint of “why does all this matter,” having remote visibility to things in real-time lets you make better decisions. It really is as simple as that. If you are a manufacturer of HVAC equipment, knowing that the pressure of the coolant in that system is 20% low, and knowing that today is going to give you the ability to make better decisions and provide better service to your customers, make the equipment last longer, etc. as compared to not knowing that information for six months until you go out and inspect that piece of equipment on its scheduled maintenance call. That’s really the bottom line: from a business standpoint, it gives you remote visibility to actionable data in real-time to enable you to make better business decisions. And because of this cell phone-driven path to low power, tiny, low-cost sensors and cheap wireless communication, suddenly this technology is in reach of almost any company as opposed to only the EXXONs of the world.
These are the salient points – the gospel, if you will – of IoT.
What Is an IoT Proof of Concept (PoC)?
A very small-scale deployment where you’re focusing on the key functionality of the desired solution. We strip away everything that is not necessary beyond the key functionality that you’re trying to evaluate. For example, if you’re trying to determine whether or not measuring atmospheric pressure is going to give you useful, actionable data for your factory, then the first thing we would do is create a minimalist solution – almost a laboratory test, in a way – that we can put some barometric pressure sensors into your factory, collect that data in a way that can determine whether it’s going to be useful or not before we spend any time and money building a whole application around that process. It’s a minimalist implementation that strips away everything but the core or key functional aspects, and to some extent it could be deployed in a very small scope among data testers or in maybe a couple of test environments where the idea is to basically test whether or not something will work and give you the actual data that you’re looking for.
The other thing about a proof of concept is that you will almost always learn things from the POC that will influence the requirements and objectives of the full solution development. So, it’s something that we often recommend as a way to test out a concept before you commit to the full project. And of course, this is on a case-by-case basis. Sometimes it may not be necessary and other times it may not be feasible to do it.
Is IoT right for my company?
Maybe? We have to talk to you first, of course. But, because the technology that goes into building an IoT solution has become lower cost and more accessible today, more companies could probably benefit from IoT than could have five years ago. To really know, we invite you to reach out to us and help us understand the particular problem you’re trying to solve. There is a better than probable chance that the answer to this question is yes.
What makes up an IoT solution?
This is where you get into that whole “stack.” Typically, you think about it from the bottom up. You’ve got: the thing – what you want to remotely monitor or control – what is that device that does that monitoring or control, what kind of hardware is it built with, what kind of software is that device running, how does that device now communicate to a network that allows it to send its data that is collected to somewhere else. How does that network connect to the application, which is now collecting and storing data from all of those devices that are deployed? How do analytics and machine learning apply to that data? How do users interact with that information (the application layer with visualization and user input)? How do you store that information long-term so that you can analyze the historical information? That is an IoT solution. It’s the hardware, it’s the firmware, it’s the network communication, it’s the application, the database, the analytics, it’s the user interface, data visualization, and tying all of that together into an end-to-end solution.
How is IoT different from telemetry or M2M (machine-to-machine)?
In a sentence, it is different because it is the beneficiary of the proliferation of mobile devices, etc. and it has driven the price down and the accessibility up. And that’s why it’s a revolution now.
And by the way, when the internet became public knowledge – the vast majority of people had not heard of the internet until 1993 – but it existed since 1969. The point is that the ability to do remote monitoring has existed for decades. The ability for it to be accessible – both from a cost and widespread use of technology – that’s the revolution. The inflection point in the nineties of what made the internet what it is today, was a culmination of different trends that – over the years – had made it more accessible. Between 1969 and 1993, it was used primarily by the government and the military because they were the only ones who could afford it, and by universities who were funded to advance it. So we’re seeing the same kind of thing happen here with IoT, which many companies/industries – particularly large companies/industries have been using different kinds of telemetry technology for decades, but until IoT, it really hasn’t been accessible to the masses.
What are “things” in the Internet of Things?
It’s typically a piece of equipment or object that you are trying to remotely monitor. It could be an HVAC system or it could be a field full of corn plants. It is the thing that you want to remotely monitor or manage. A thermostat in the building, part of the building itself, it could be a truck, it could be a corn crop, it could be a cow. Most IoT is one-way – we’re collecting data and making use of that data. But of course, you can also send commands downstream and in some cases, remotely control those things. Soil moisture probes and hyperlocal weather stations are good one-way examples, and remotely monitoring pipe pressure and then remotely controlling the shut-off of a pipe is a good two-way example. The “thing” is any of those things.
And by the way, the reason the term “Internet of Things” was coined, is that we typically think of the endpoints of the Internet as being people – “I am on my computer/phone using the internet.” The internet of things is that the endpoint is not a person. It’s a thing.
Connectivity
What wireless standard is best?
Well, “best” for your solution is different than “best” for someone else’s. And ObjectSpectrum is not tied to any particular wireless or connectivity standard of any kind. We regularly use a number of different technologies, and that is part of the design phase of any solution – to determine what the right technologies are for a given solution. Of course, that’s true no matter what technology we’re talking about (not just the wireless standard). Tracking ships at sea will necessitate a very different wireless technology than something that needs to keep track of pallets in a warehouse. It just depends, but we are not tied to any particular technology.
What web browsers and mobile devices does ObjectSpectrum support?
All modern browsers and mobile devices.
Locating & tracking assets is important to my business. Can ObjectSpectrum provide this capability?
Yes. When you talk about asset tracking, that’s a very generic term. One of the built-in capabilities of Prism is the underlying building blocks of asset tracking, which includes things like GPS coordinated math and mapping, visualizations, geofencing logic, etc. But the advantage of using Prism and ObjectSpectrum comes when you get past the basic idea of GPS locating and asset tracking. This is where your specific needs come into play – what exactly are you tracking? Is it outdoors, is it indoors, is it something that needs to go anywhere in the world? Is it something that only moves around in a campus or a factory? Are you keeping track of more than just its location? Do you want to know information from other sensor inputs on it with data that needs to be tracked and reported? When you get into the specifics of an asset tracking application, that’s usually where we have a big advantage that we can bring to the table, because we are certainly more than just an asset tracking solution.
Is a cloud service always required for an IoT application?
No. There are cases where there is a cloud connection, but the cloud connection is primarily there to collect data for analysis, and the function for the application that it is performing is completely local. That might mean that the application is running entirely on the phone, or it might mean that there’s some local process, computer, or device that’s actually running the application, so it doesn’t need the cloud to operate. It can connect to the cloud if the cloud is available, but it doesn’t rely on the cloud to operate and do its job. It’s an application that can run self-contained if it doesn’t have connectivity to the cloud.
Can ObjectSpectrum integrate with public wireless networks?
Yes, including everything from cellular carriers to public LPWAN providers. We are already pre-integrated with all of the major carriers in this space (like AT&T, Sprint, T-Mobile, Public LPWANs, different regional LoRaWAN providers, etc).
Hardware
Does ObjectSpectrum support devices with Hazardous Area certifications?
Yes, we do. That’s really about the device itself. So, if we had an application that had sensors for a hazardous environment, we’d have to support devices with Hazardous Area certifications. But from our perspective, it doesn’t really matter that much because Prism is not in the hazardous environment. Your solution is almost always in the cloud. The exception would be on-premise deployments or certain edge computing hardware, and of course, options generally exist for those that have Hazardous Area certifications, too.
What is a Camera as a Sensor?
Camera as a Sensor is when you use video input from a camera (which could be visible spectrum or it could be outside the visible spectrum, such as an infrared camera), and the purpose of the camera is not to send a live video stream back to the application, but instead to capture the video feed, use some type of edge computing (often machine learning) to interpret the information that is being captured by the camera, and then return small bits of sensor data instead of sending the whole video feed. For example, a visual spectrum camera is watching a parking lot and we want to know how many empty parking spaces there are in that parking lot. One camera could potentially see the entire parking lot and allow us to quickly count and transmit the number of cars or empty spaces in the parking lot instead of putting a sensor on every single parking space. Another example would be an infrared camera that is pointed at a particular piece of machinery. It could watch for hot spots on that machine and only transmit an alarm if that machine hit a temperature threshold that was set by in the application. Instead of putting a bunch of temperature sensors all over this machine, one infrared camera can detect the temperature at all 73 places on the machine and send an alert when any one of those 73 places gets too hot.
Check out this blog post that goes into greater detail.
What is “edge computing” and when is it needed?
Think about the “edge” as being the physical location of wherever the IoT solution is happening remotely. So, it’s not where the user is. It’s where the remote thing is. For example, if you are monitoring a generator in a factory, the “edge” is where that generator is in that factory. So, when you hear “edge computing,” it’s basically saying “instead of the computing going on in the cloud somewhere, the computing is going on at the site of the thing.” The reason you might want to do this is because: a) you may not have time for the two-way communications to make the round-trip to the cloud and back (called “latency”), b) it might be in a remote spot where a connection to the intent is spotty or non-existent, and/or c) the nature of the remote sensing can benefit from doing some of the work locally to reduce the bandwidth needed between there and the cloud. It moves the computing to the place its most needed. That speeds it up, and that means it doesn’t have to be connected to the internet, or can use less bandwidth, to function.
The “edge” could be literally on the device itself, or it could be some type of a local computing appliance or other computer that is located near or within the place where the data is being collected.
Typically, edge computing is used when you need to make very quick decisions – when you don’t have time to send measurement data to the cloud, have the cloud to the analytics, and then send the command back to the device. That is called latency. Even if that process is very, very quick, there is a fraction of a second that it takes to send those messages back and forth. And in certain applications you have to make those decisions very quickly.
Another case for edge computing would be cases where you had very limited bandwidth. For example, if you had some type of a sensor – like a camera that was collecting a lot of data for video that requires high bandwidth – but you were using the edge computing to count the cars that were in the field of view of the camera. And all you cared about was the number of cars. That’s a case of edge computing taking very high bandwidth information – the video – and turning it into very low bandwidth by just relaying the message, “there are seven cars now.”
The last of the big three reasons to use edge computing is if you need the system to be able to operate without being connected to the cloud. This is less being about “cloud-optional” and more about being fault-tolerant. If you have a system that you can’t afford not to work if your internet connection goes down, then edge computing is one solution for that. Where it can make local decisions, or continue to collect data until the internet connection comes back up again.
Those are typically the big three: 1) to solve latency (need it to be fast), 2) when you have limited bandwidth (does the high bandwidth stuff locally and converts it into low bandwidth information), or 3) when you have spotty internet connectivity at the site where it’s collecting data.
What is LoRaWAN?
LoRa stands for “long range,” so it the word literally means “long-range wide area network.” It is a low-power WAN modulation technique that uses license-free frequency bands to transmit small amounts of data – either over long distances (ten miles or more) or through obstructions like buildings, typically being able to penetrate several concrete walls. It’s used in a lot of applications, including agriculture, smart buildings, smart cities, where you need either the long-range or the deep building penetration capability to wirelessly collect data from sensors and/or wirelessly send commands to actuators. It is often used in applications that need to be very low power, like battery-powered devices that last five years or more on a battery, or energy-harvested devices, like devices that run on solar power virtually forever. It’s a wireless technology that can either be operated on a private network or on any one of a number of public networks that provide LoRaWAN connectivity for a monthly fee. LoRaWAN is one of the wireless technologies that we use at ObjectSpectrum, and often includes network management services for private LoRaWAN customer networks as part of the solution. We are also member of the LoRa Alliance, which certifies LoRaWAN devices.
What is BLE?
Bluetooth Low Energy (BLE) is a relatively short-range technology that is universal (works on the same frequency anywhere in the world), very accessible (every smart phone has BLE capability), and it is also for transmitting relatively small amounts of data. It is not the same as Bluetooth. Bluetooth Low Energy is not Bluetooth, but of course they are often easily confused. They are related to each other, but Bluetooth has enough bandwidth that you can send high quality audio over it to your earbuds. BLE is designed for low-power devices with small amounts of data. For certain applications where you don’t care that much about range, and/or you want to be able to connect directly to an end user’s smartphone (one example of this is cloudless IoT applications), then BLE is often a good choice because it has that universal accessibility combined with the ultra-low power capability that no other technology really has, meaning you can build battery-powered BLE devices that last for years on a battery. Another place that we would tend to see BLE used is as a secondary wireless technology used on a device that may have a LoRaWAN or a cellular radio on it as its primary communication link, using the BLE wireless device as a way to configure or provision the device (because it can be done using any smartphone). It’s not super common, but it does happen.
What is “device management”?
Device management is the ability to add a device to whatever kind of network or connectivity that device is using to communicate. That process is usually called provisioning. You are provisioning a device on a network. That could be a lot of different things, but one example of that would be provisioning a device on a cellular network. That is how you set that device up so that it can connect to and send data over the cellular network. That’s the first part of it. The second part of it is when you have large quantities of these devices, you need some way to manage those devices. You need some way to detect that a device is not working anymore. If it’s battery-operated, you have to check the battery’s charge to make sure it’s not running out. And if the devices can support “firmware updates over the air” (FUOTA), you need a way to manage that. These are all things that are typically done as a part of device management. It doesn’t necessarily have anything to do with the device, nor with the application – it has to do with how you add, monitor, troubleshoot, replace, and ultimately remove the physical devices from the communications network they’re communicating on. And, depending on the particular requirements, Prism can either include device management as part of the application or it can integrate with third-party device management platforms when appropriate.
What is a “gateway”?
A device that has the only (or primary) job of routing data from one technology to another. So, for example, a LoRaWAN gateway is one that sends and receives messages over the LoRa wireless technology and then relays that information back to the cloud, possibly using cellular technology, or maybe just a direct connection to the Internet. And some gateways can have additional functionality beyond that, like computer resources for edge computing, but that’s the basic gist of what a gateway does—it translates data between different networking technologies.
What third-party sensors and devices does ObjectSpectrum support?
ObjectSpectrum supports just about any third-party sensor and device. We have the ability to rapidly integrate new devices. We aren’t limited by any particular list or kind of sensor or device. We figure out what the best solution is for what you’re trying to do, and we are completely agnostic when it comes to the device or any other technology it uses. We can integrate devices from different manufacturers with different technologies so that we can use the best in class for your specific solution’s needs. As a general rule, we try to use off-the-shelf sensors and devices whenever possible, but will work with our partners to develop custom hardware when that’s needed.
Security
How does ObjectSpectrum protect my data?
There are a few different areas to protect:
- Access Control/Authentication – who or what has access to that data. Depending on the specific requirements of a particular solution, that might be anything from password protection to using some type of two-factor authentication to using secure certificates for third-party API integrations. But regardless of the method that you use, to be able to authenticate the user or the third-party that wants access to the data and then make sure that – based on their authentication – they only have access to the data that they’re allowed to have access to. Who has access and how do we authenticate that they are who they say they are.
- Industry-Standard Encryption – we use industry standard encryption wherever it is possible to do so, for both data at rest (data we’re storing in a DB) and data in transit (being transmitted somehow – over the internet, over the air, etc.). So, that includes things like using TLS (transport layer security, which is what browsers use for banking-grade secure connections) and AES encryption that is used on both live data in the database and for backup data.
- Segregation of Data – in our shared-tenant hosting infrastructure, where we have multiple applications and customers all running within the same physical infrastructure, the architecture of Prism is such that all code and all data that is related to a specific application, and even a specific customer instance of that application, is completely isolated from all other data. That is built-in to the architecture of Prism, specifically for this purpose.
Is IoT secure (or can IoT be secured)?
IoT – like any technology – is not necessarily inherently secure. But when you design a solution, you design it with security in mind. And that means using best practices, it means putting in an appropriate level of security for the data for the application in question, it means making sure that all of the components that are used in the solution can be secured. And so, not only is security something that was built into Prism from the ground-up, it’s an inherent part of the architecture, but we also – as part of any solution design – will incorporate security best practices and ensure that third-party components are either also incorporating those best practices or that appropriate modifications can be made to bring them up to that standard.
How does ObjectSpectrum secure API access to my solution?
It would almost always be over a secure, encrypted connection. It would be very strange for it to not be. We can do anything from as simple as a static, pre-shared token that could be sent as part of the API request, to various types of key or certificate-based calculated tokens, to VPNs. For API we could set up VPNs between the party that wanted to access the API and our system. That’s kind of a continuum from a static secret token to VPNs – running the gamut from simple to sophisticated.
Robotic Process Automation (RPA)
What is Business Process Management (BPM)?
Business Process Management (BPM) is a methodology that helps organizations design, implement, monitor, and optimize their business processes. It focuses on improving efficiency, reducing costs, and enabling adaptability in workflows across the entire organization. BPM aims to streamline operations and eliminate bottlenecks in routine tasks. A key component of BPM is automation, with Robotic Process Automation (RPA) being one of the tools used to automate repetitive, rule-based tasks. While BPM covers a wide range of process improvements, RPA is specifically focused on task-level automation.
What is Robotic Process Automation (RPA)?
Robotic Process Automation (RPA) is a technology that automates repetitive, manual tasks typically performed by humans, such as data entry, processing transactions, or generating reports. It allows businesses to improve accuracy and save time by handling routine digital tasks. RPA is an integral part of Business Process Management (BPM), helping streamline individual processes within a larger operational framework. At ObjectSpectrum, we supercharge traditional RPA by integrating IoT, which expands automation into physical tasks. To learn more about how we enhance RPA with IoT, check out our RPA + IoT page.
What’s the difference between traditional RPA and IoT-driven RPA?
Traditional RPA focuses on automating tasks that humans routinely perform on a computer, like data entry, processing forms, or even sending emails. IoT-driven RPA takes it a step further, automating routine physical tasks that your employees or contractors do outside the digital world. Think about real-time monitoring of factory inventory levels, equipment maintenance, or even environmental conditions. We integrate IoT sensors into your existing RPA setup, giving you automation for the physical world, not just the digital one. For more information, check out our RPA + IoT page.
How can IoT improve the RPA system we already have?
If you’ve already invested in RPA, that’s a great start. IoT can supercharge your current system by automating tasks you never thought could be automated. Imagine combining the digital tasks your RPA handles with real-world monitoring: checking the levels of raw materials in your factory, ensuring HVAC systems are working optimally, or even inspecting critical infrastructure like roads or bridges—all without human intervention. With IoT, your RPA becomes a complete end-to-end automation solution optimized for your specific business operations. For more information, check out our RPA + IoT page.
Why should I integrate IoT into my business if we’re not using RPA yet?
Whether or not you’re using RPA, the goal is the same—efficiency and boosting your bottom line. By integrating IoT, you automate routine tasks that consume valuable employee time and introduce inefficiencies into your operations. Think about it: instead of sending someone out to check inventory, monitor equipment, or inspect conditions, sensors do the work for you in real-time. This frees up your team to focus on higher-value tasks, cuts down on errors, and ultimately puts more money back into your business by reducing labor costs and increasing operational efficiency. The result? Massive savings, streamlined processes, and more profit to your bottom line—without the hassle of manual oversight. For more information, check out our RPA + IoT page.
How does ObjectSpectrum help with RPA + IoT integration?
We don’t just give you sensors and software and walk away. At ObjectSpectrum, we build IoT solutions that integrate seamlessly with your existing RPA software. Our Prism platform enables you to gather data from the physical world and use it to automate tasks just like RPA does in the digital space. Whether it’s monitoring fuel levels, checking motor conditions, or managing factory orders, we create custom end-to-end IoT solutions tailored to your business. For more information, check out our RPA + IoT page.
How do you differ from custom software or web development firms when it comes to creating RPA + IoT solutions?
The big difference? We’re experts in IoT. Custom software developers or web dev firms may know how to build websites, apps, or e-commerce platforms, but IoT is an entirely different animal. We’re not starting from scratch; we have purpose-built software, tools, and intellectual property designed for IoT that get you 70-80% of the way there from day one. That means faster, cheaper, and lower-risk solutions. And we stay with you for the long haul, offering support, updates, and monitoring throughout your IoT system’s lifecycle. For more information, check out our RPA + IoT page.
What kinds of physical tasks can be automated with RPA + IoT?
There’s practically no limit. Some examples:
- Inventory Monitoring: Keep track of chemicals, raw materials, fuel, and more—automatically.
- Equipment Inspections: Check the status of motors, pumps, HVAC systems, and fire extinguishers without sending a human.
- Environmental Monitoring: Measure water levels in rivers, air quality in facilities, or temperature conditions in storage rooms.
If your business involves routine checks, inspections, or monitoring, IoT can automate it. You’ll save time, reduce labor costs, and eliminate human error. For more information, check out our RPA + IoT page.
How can RPA + IoT help us reduce labor costs?
RPA + IoT eliminates the need for employees to perform repetitive tasks like checking inventory, inspecting equipment, or monitoring environmental conditions. Sensors do the job for you, sending real-time data to your systems and automatically triggering actions when needed. This frees up your employees to focus on higher-value work while reducing manual errors. Bottom line? Fewer labor hours spent on routine tasks means lower costs for your business. For more information, check out our RPA + IoT page.
Why does adding IoT to RPA require a specialized skill set compared to other RPA-only projects?
IoT isn’t like building a website, app or even simple RPA software. It’s a deep stack of technologies that involves hardware, software, networks, and data processing—all interacting in real time. A web developer may be great at creating an e-commerce platform, but that doesn’t mean they have the expertise to manage the creation of a custom, end-to-end IoT system. With ObjectSpectrum, you’re working with a team that has extensive experience at all levels of the IoT stack, from sensors to cloud systems. We bring the expertise you need to develop a secure, scalable RPA solution that works for your business. For more information, check out our RPA + IoT page.
What can RPA + IoT do that RPA alone can’t?
RPA automates tasks within a computer system—like data entry or processing orders—but IoT extends automation to the physical world. IoT can check equipment, monitor environmental conditions, and report on physical assets in real time. This means that tasks you never thought could be automated—like checking the level of chemicals in a tank—are now fully automated. It’s like giving your RPA system eyes and ears in the real world. For more information, check out our RPA + IoT page.
What if we already have a web development company—can’t they handle adding IoT to our business processes?
Chances are, they can’t. IoT is very different from web development or software development. It’s not just about coding; it’s about managing a complex stack of IoT technologies that includes physical sensors, cloud computing, and real-time data processing. Web dev firms – or RPA software development firms – often don’t have the expertise or tools needed to build reliable IoT systems. That’s where ObjectSpectrum comes in. We focus exclusively on IoT, so you get the deep knowledge and experience you need for a successful RPA + IoT project. For more information, check out our RPA + IoT page.
Why should we choose ObjectSpectrum over other IoT companies to combine IoT with RPA?
ObjectSpectrum doesn’t just specialize in IoT—we excel at combining it with your existing RPA systems to create a seamless, end-to-end business process automation solution. Our Prism platform is explicitly designed to integrate IoT data into RPA workflows, ensuring that tasks in the physical world are automated just as efficiently as digital tasks. Unlike other IoT companies, we bring deep expertise in both fields, providing a custom solution that fits your business needs. We also offer ongoing support, monitoring, and updates, so your system stays optimized over time. When you choose ObjectSpectrum, you’re getting a partner with a proven track record in both IoT and RPA integration. For more information, check out our RPA + IoT page.
Can you give an example of how IoT and RPA can work together in my business?
Sure! Let’s say you’re running a factory, and your current RPA system manages orders and schedules deliveries. By integrating IoT, we can add real-time monitoring of your raw material levels. Instead of having employees manually check the tanks and bulk bins every day, sensors automatically track inventory and send updates to your RPA system. When levels get low, the system can automatically reorder supplies—no manual intervention required. It’s an end-to-end automation solution, from the factory floor to your backend systems. For more information, check out our RPA + IoT page.