Blog

Big Data Analytics for Predictive Maintenance in an IoT world

2013-05-21T18:52:29Z

Big data analytics is a bigger topic today and use cases are arising in many areas of business. These range from the traditional CEP areas of financial trading to new customer engagement models such as geo-located coupons. In an Internet of Things (IoT) world, machine to machine (M2M) solutions can produce big data requirements. These, ‘edge devices’ can post vast volumes of data into the cloud applications that service them. Manufacturing is an area, under-served by BPM and there certainly are numerous industrial M2M and big data use cases. At Bosch, we believe one of the most important and fruitful areas are predictive maintenance (PrM).

Factory floors frequently have expensive and complicated machinery that is critical to their manufacturing competitiveness. The unplanned loss of even a few Hours can result in a great financial loss. . Many companies are turning to the big data, analytics topic of predictive maintenance to optimize these resources. These methods analyze the condition of in-service equipment to project optimal maintenance measures. Analytics for this fields encompasses a broad range of mathematical disciplines, for instance vibrational analysis can use the occurrence of even a small 'out of round' sensor reading to predict the failure of a machine. When we start to aggregate a number of machines, one can apply data heuristics discover even more predictive factors. Even minor irregularities and latent failure patterns are uncovered and aligned across the resource pool.

It is not enough to have the mathematical, material science and engineering capability to create a predictive maintenance solution—— there needs digital infrastructure to support this. That infrastructure must also be capable of hosting M2M solutions. Bosch software already has an example of this in the Service Portal.

The service portal uses A combination of BPM+ and the output of predictive analytics to generate the appropriate response.

On June 6, 2013 Bosch Software will hold a webinar on their approach to PrM.

http://www.bosch-si.com/company/news-events/events/events-16896.html .

I will be speaking along with my colleagues Karsten Koenigstein and Christina Gruen.

Process Interactions in Orchestrations and Choreography

2013-05-17T18:58:26Z

We have common definitions for process, business rules, operational decisions, business events and other things that are important to process modeling. And, I have mentioned my favorite ones (here). But we frequently ignore one of the very important aspects of process modeling: interactions. Fingar and Smith mentions in ‘Business Process Management, the Third Wave' that an interaction is the use of process desktops that allows people or participants to interact with the process. This includes workflow emphasizing assignment, task management and form-based data entry. So, interactions gave rise to the idea of task oriented process instances that are started by a form. We see this in today’s process monitor and task list in most BPM suites. A form is a completed interaction that spawns an instance. This was, arguably, a new concept in 2002.

The BPMN 2.0 specification (here) also delves into the concept of interactions. Section 10.1 says that a public process represents the interaction between a private business processes and another processes or participants. The interaction is the glue. In the specification, human interactions are a type of task with human involvement. Manual and human tasks have particular icons in BPMN that indicate that human involvement is required to complete the task. See the two figures below.

The Human Task & Manual Task

Remember: a manual task is a task that is expected to be performed without the aid of any digitized business process. An example might be the nurse delivering medication to a patient. This is contrasted with a user task which is performed with the assistance of a software application or is scheduled through a task list manager. An example would be the approval of a request or deciding a proposition.

Interactions are critical to the concept of choreography. A key characteristic of choreography is that it is an activity representing an interaction between two parties rather than a unit of work. According to Dumas, "The Fundamentals of Business Process Management”, the interaction can be one-way, where a message is exchanged or two-way, where messages exchanged bring a return message. Each message has an initiator and a recipient. Indeed, the BPMN spec states that "choreographies formalize way business participants coordinate interactions. This gives rise to the 'conversation' shape center defined in the spec.

In Wikipedia the interaction is defined as ‘a kind of action that occurs as two or more objects have effects upon one another’. This is fundamental in the concept of the business process.

White Space in the Standards: Business Rules, Data and Process Modeling in BPMN

2013-05-02T19:38:23Z

According to the Specification (here), BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope for BPMN. Therefore, the following are out of the scope of the BPMN specification:

Definition of organizational models and resources
Modeling of functional breakdowns
Data and information models
Modeling of strategy
Business rules models

Since these subjects are critical to Business Processes, the relationships BPMN is supposed to be evolving. We also know that operational decisions need data to decide, so at this point BPMN is incomplete with respect to creating executable business processes. An executable BPMN diagram might be more complex — it is inadequate to create an executable specification.

BPMN has a data shape, the data object. A data object is a rectangle with the upper right corner folded over, as shown here:

The text label for a data object can be found underneath the shape. Often the current state of the data object is shown as an attribute shown in brackets under the text label. As the diagram progresses, the state of the data object can easily be read, as displayed in the Figure below.

Figure: Use of data artifact shapes.

As with the text annotation, the association line attaches the data artifact to another shape. Data Class shapes can be associated with tasks, gateways, events, sequence lines, or message lines. In message flow, data objects portray the “payload” or content of messages.

The use of data objects is optional. Some diagrams may concentrate on flow, while others show the complete details Data artifacts do not directly affect the sequence flow or message flows. Data objects provide additional information, some of it reflected in the XML schema, without changing the basic behavior of the process. For instance, the Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object. The data object can detail the metamodel’s XML particularly with a ‘callableElement’. Uses the following additional elements:

ioSpecification,
inputSet,
Data Input,

The data input and output are detailed in the purchase order approval example above. When a BPMN editor draws a Data Association to an Activity or Event it should generate this supporting invisible substructure.

As mentioned, the specifications are naive with respect to the origin mutation and alteration of data attributes. I've always maintained that this is the realm of business rules (mostly). That business rules through examination of data in order to decide Bolivian conditions controls specific aspects of operational decisions. Some of that data exploration includes analytics such as regressions, projections, and other techniques.

I believe the BPM industry needs to progress on standards with respect to business rules: the representation how they use things like Business Objects expressed in UM, and other expressions of the operational aspects of the business process. The BPMN specification pretty much admits weakness in this. So, even with the data input and output elements of BPMN, more needs to be done in order to specify a business process in a way that does not very important code aspects. The OMG spec on business rules (PRR) seems to be moving very slowly and it doesn't offer a clear connection to the process modeled by BPMN.

Introducing a new white paper: The Five Categories of Operational Decisions and their Impacts on Business Process Models

2013-02-21T19:29:27Z

Business processes should enforce compliance to operational, legal and risk objectives. Yet how can one be assured that their processes are compliant? Increasingly, the best practices is to use a combination of business process modeling with a business rules approach- the operational decision (OD) approach. These frequently occurring, repeatable decisions are key to enforcing compliance.

A combination of BPM, OD and event processing can create comprehensive, agile solutions in many problem domains. In a new white paper from Bosch Software Innovations, we explain the role and interrelationships of these different visual modeling approaches. Most process modeling methods parse directly requirements into BPMN process elements. They incorporate with workflow patterns. There are alternate approaches that start with business rules and Bosch Software Innovations can support either. This white paper discusses how to develop processes requirements from a business rules perspective. Starting with this definition of a business process:

A business processes is an organized, coordinated flow of activities, conducted by participants, acting on and deciding with data, information, and knowledge, to achieve a business goal[1].

We can design a digitized business process based on business rules that describe the means of compliance, operational controls and risk mitigation[1]. So, from the perspective of the business process as per Ron Ross:

“A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or influence the behavior of the business.”[2]

The objective is the digitized process so the rules are expressed in executable, directed graphs and decision tables. When we design processes, we are defining the behavior of the business, so that processes comply with business rules by making operational decisions—a rules-compliant process.

Operational decisions are frequently occurring, repeatable decisions that implement the compliance, operation and risk controls. They are settled with process data and evaluated by digitized business rules. So a business rule is an atomic logic step that uses data and knowledge to evaluate a part of a proposition about a process decision³.

In a BPM/Business Rules approach, processes are activated by business events. Chandy and Schulte[3] define a business event as:

”A business event is an event that is meaningful for conducting commercial, industrial, and governmental or trade activities.”

The differences between process, rules and business events are simple; rules are overarching, stateless directors of behavior, processes are stateful responders to the directives, and external business events, are detected and processed.

The recent research of Martijn Zoet, Richard Welke, et al found that business managers expect business rules to govern and control business operations with on five concepts:

Rules should influence, order or sequence a process’ tasks, decisions and internal events
Rules should influence and decide who is included in and assigned to a task
Rules should influence and decide what course of action is taken
Rules should influence and decide what data is retained, its validity, and duration and
Rules should detect, control, and respond to events

When they are dynamic or controlled in a BRMS, these five concepts are categories of operational decisions. Static elements become elements of a business process map or diagram—transitions, activities and gateways. We described five different ways that a decision’s outcome can direct the pathways of the process. As a nexus for governance, risk and regulatory compliance, the process decision is both an important management concept and a strategic design tool for achieving business objectives and goals.

Our new white paper clearly demonstrates how the 5 categories of decisions create processes that are compliant with the operational, compliance and risk management objectives. We lay out an effective design method that recognizes that process behavior considers decision-generated events. Also, from a single operational decision, events and data can trigger and control many aspects of a business processes.

The figure below depicts these 5 categories:

The Bosch Software Enterprise Platform provides a powerful design environment that simplifies management control of business processes. The result of separating processes from rules stabilizes business processes and permits operational decisions to change without having to change the process application. Understanding the five operational decision categories simplifies the choice of what should be a dynamic operational decisions supported by business rules and what should be a static part of the process. The white paper presents approaches for deciding what should be an operational decision (business rule) and what should be on the BPMN process diagram (gateways and conditions).

You can download the complete white paper here:

[1] Martijn Zoet, Richard Welke, et al, ‘Aligning Risk Management and Compliance Considerations with Business Process Development’, Springer-Verlag, Berlin Heidelberg 2009

[2]Business Rules Group, Defining Business Rules ~ What Are They Really?, www.businessrulesgroup.org

[3] K.Chandy, R. Schulte, Event Processing: Designing IT Systems for Agile Companies, McGraw-Hill Osborne Media, 2009

[1] The Microguide to Process Modeling in BPMN 2.0, Debevoise, Geneva and Welke, Advanced Component Research, 2010

Advanced Business Rules Capabilities Address Complex Challenges

2012-09-18T09:08:14Z

At Software Innovations, we have added some interesting new customers including Green Charge Networks and Prosper Software. In addition to other projects that we cannot mention, these development shows how Visual Rules, modeling approach can solve complex challenges in our Big Data, highly dimensional, customer-focused social ecosystem.

The Juila set is a highly recognizable symbol for complexity as develops in the study of fractals and chaos.

From our discussions on the internet of things ( and here) and other developments, we know that today’s world of mobile-networked-social media presents new opportunities for business models and customer engagement. Example models include freemium where a service is provided free of charge, but a premium is charged for advanced features. Another style is gamificationwhere game thinking is applied to non-game applications to encourage people to adopt them. These seemingly simple, yet powerful concepts often require deep layers of implementation business logic.

This ecosystem is also being extended by sensors and edge devices in the IOT. For instance; heart monitors provide data to doctors, or fitness appliances through ordinary smart phones. Sensors on bicycles provide detailed data. These products are a visible outgrowth of the internet of things and services (IoTS); yet, to create applications one must leverage the extreme granularity of this.

In addition to the exotic, new world of the IoTS, traditional data sources have exploded in granularity and accuracy. Most of the decisions of the inputs into the operational decision include time based vectors of:

Location, derived GIS stored locations, and proximities
Awareness of proximal individuals and groups of individuals,
Edge device feeds, heart rate, temperatures, video, weather

Emerging business models use applications: mobile, cloud and on-prem, to operationalize decisions. The decisions will tell customers what to do or make decisions- this is critical. This means that companies must make effective use of this highly dimensional and time dependent data, often in nearly real-time. To achieve their objectives in this new world, these business require perception of environmental elements with respect to time and/or space or situational awareness.

The complexity arises in problems areas when ordinary, yet challenging business rules areas such as consumer retail and end-use applications, security command and control, complex financial transactions, and products with highly hierarchical catalogs, are combined with real time motions of people, vehicles or traceable financial instruments. The characteristics of this might include large, time dependent vectors of business objects. In this highly dimensional area, each data point exists in the time-location space defined by its attributes and by its relative relationship to all other time-location data points. That relationship is the domain of business rules and the pivot points for the decisions that we are describing. In this realm, the goal of the decisioning and operational decision algorithms is to assign the data point to membership in the most appropriate cluster—even as the subject is in flight. Business Object Data Collections can be linearly separable or non-linearly separable. We have found, particularly these data are often arranged in a vector that must be efficiently traversed.

The company building applications in this complex, operational world faces the dilemma of hand codding solutions or using visual modeling paradigms. These problem often entail an huge number of logic steps with the need to make subtle changes at deep levers. At Bosch Software we believe that only the latter is sustainable.

In our experience, visual metaphors are mandatory for solutions in this ultra-complex, highly evolving world. The business analyst must be able to use their intense focus on business aspects while the technical teams provide a mastery of the technical aspects for a seamless transfer of logic changes. As a demonstration of this, visual rules, business modeling has recently solved problems in these domains:

An athletic consumer products company seeking to operationalize decisions about fitness equipment
A company with an innovative financial model built a multi-dimensional, dynamic pricing engine
A financial institution created dozens of credit score cards, each with over 90 equations and 190 dimensions.

In solving these problems for many customers we have learned the following:

Complex dimensional decisions can only be understood when they are ‘chunked’ into simple visual metaphors, otherwise business analysts get lost in code or simply give up.
Visual paradigms including decision graphs, decision tables, state-transition diagrams and composites of these are the only way to quickly solve these challenges.
Because they cannot traverse and filter vectors of business objects, Decision table-only approaches tightly constrain the type of problem that can be modeled and miss important dimensional aspects of these classes of problems.

In Summary, business operating in this new realm should expect change and build methods that create the proper agility.

Note: On September 27 at 2PM EST, Troy Foster, our CTO for the Americas will cover these topics in detail. You can register for this webinar here: http://www.bosch-si.com/webinar-on-advanced-business-rules.html

Messages and Sequences in a ‘Requesting Feedback’ Process

2012-07-08T14:52:31Z

In a linked-in question on the BPMN group, Lotfi Al-Hussami posed a basic modeling problem in BPMN. Quoting here:

“As an example, we have the following process that we will call "Get feedback":
- A company X "Send forms" to people by e-mails
- People fill forms, so every person receiving the message "Fills form"
- Company X "Process forms"

At first glance this looks like a pretty simple problem to solve, as shown in the process below. If the process merely prepares the correspondence then our process, ‘get feedback’ will handle the messages as shown below:

So the location of the intermediate event is dependent on what level the process is responsible for the messaging. Strictly reading the name of the first subprocess in our example the first example is probably most correct. Also, we are using the external black-box pool to denote the customer.

The Survey Pattern

In many cases, organizations want to aggregate feedback. Sometimes a process gathers data from an unknown number of participants. The process requirement wording might be:

Request feedback from at least %20 of the customers.
A minimum of 20 participants are required for the class to be scheduled.

The process does not know the number of instances of an activity at run-time. We can use a survey pattern when we don’t know how many responses or instances of an activity happen. Here the process must wait until all instances are completed. Then other activities start. Often, while some activities execute or are completed, new ones might be created- your process might ask for more responses. This

A Survey Process

The figure below presents a model of the survey, marketing or feedback scenario. In the example an email form invites a response from customers in the process. The loop awaits a satisfactory response, as determined by a decision. Here is a short description of the process:

An incoming message starts a survey. The ‘email Recipients’ task send email to a mailing list.
The survey process loops for incoming email. The results of the survey are tallied by the ‘survey decision’ activity, which calls business rules that decide the adequacy of the survey.
A gateway decides if the survey results are satisfactory. Usually the gateway is optional. BPM tools specify the looping conditions.

The black box pool shows a notation, verticle bars, for multiple customer participants.

Other examples of the usages for this pattern include:

Getting bids for work from multiple trading partners,
Awaiting the delivery of multiple shipments from vendors to a facility before completing a process.

The multi-participant pools should be displayed in this case. You assign this pattern when the process must respond to multiple unknown quantities of events.

The elements of the pattern are:

A request from multiple sources by email, messaging, html or other sources
A loop that awaits the arrival of information from these sources
A decision to approve the survey and business rules for this decision: a call to the rules engine to decide when the survey response is satisfactory.

A process that receives the request and loops between the approver and requestor until the approver is happy with the request.

Cardinality is the Key

Returning to Mr. Al-Hussami example, process-oriented thinking should focus the requirements on a single instance of an interaction. So, a single survey form should be met by a single process response. We can compose a working, single-person survey into a more powerful pattern, such as the pattern that we have described here. When you are working with process requirements in BPMN, verify that you are thinking in terms of the singular entity, and then build your requirements from there.

Starting Processes Multiple Ways in BPMN

2012-06-12T11:47:45Z

In BPMN 2.0, there are several ways to start processes with multiple events. There is a ‘multi-start’ event which looks like this:

Because they are abstract, multiple events can be hard to understand. Generally, a multiple event is "shorthand" notation for multiple events triggering a process. Triggers could include messages, timers, conditions, signals, escalations and other event types.

So, usually when a modeler is working with a requirement to start a process – multiple ways, we suggest the multiple-event gateway. With event based gateways, a path is chosen based on an event. For example, "web form" is a possibility. Also, there could also potentially be no response at all. The Figure below shows an example of handling all three of these events from one gateway.

Multiple events on a event based exclusive gateway

The event-driven exclusive gateway can come in the start of a process, or in a sequence as an intermediate shape. When the gateway is at the start of the process, the event shape inside the diamond is the start multiple start event (single thin line). The figure shows the use of the intermediate, event-driven gateway after an ordinary start of a process. The BPMN2.0 spec also has a starting form with a single thin circle at the center. We end the pattern with a data-based exclusive merge because with the ‘exclusive’ type of the multi-start gateway.

There is also an inclusive form of the event-gateway, but that is the topic for another conversation.

Build Survivable, Hardened Cloud Processes with BPMN

2012-06-05T13:33:56Z

Integrating the cloud into your error processing strategy can be challenging. Fortunately, BPMN provides a powerful approach to managing failures, in the form of exceptions and compensations. Adding resources and services into the ‘Cloud’ adds error points that must be managed. The designer of these processes should strive to make their processes ‘survivable’ and hardened. The exception shapes and compensations allow continuous operation throughout intermittent error conditions such as those encounter in integrating cloud services and resources. Without a hardened process your participants might need to use a manual process for the exception flow. This can be an outcome of overfocus on “happy day” paths. Manual processes promote staff improvisations and undocumented “work arounds” and obviously should be avoided.

Figure 1 presents an example of BPMN’s modeling of survivable processes in a survey pattern. If an error occurs in the email-reading process, it can be posted to a log and systems administrators can respond. The survey can continue. Finally, the process can loop back or complete.

Figure 1: BPMN for an exception in the survey process.

The aim of BPMN is to support “long-running” transactions so it is especially suited to the cloud scenario. For instance, a process-oriented car rental agency might create one process for each vehicle, each using a cloud-based machine health service. In this case, the process could run for years, with thousands of calls to the cloud-based service.

Three Error Types

There are three types of exceptions that may affect process execution:

Technical exceptions—the process server has failed
Transient exceptions—a needed resource (for instance a cloud service) for the process is unavailable
Business exceptions—the condition of the process is in error. Data is incomplete or has errors.

Unfortunately, there is no cure or notation for the technical exception. When the server halts, recovering processes are dependent on the technical nature of the process server.

Decisions, supported by business rules, can create named business exceptions. If the process is transactional, it should compensate for transactions that fail to complete. In compensation, the process cleans up or backs out records from ERP’s, operational data stores, or data warehouses – perhaps these can be cloud based.

Processes often must be completed within a specific time period, so there could be time-out actions noted on the diagram. Business processes usually receive a message and translate that message into yet another message for consumption by the next part of the process. BPMN is powerful for developing time-outs, exceptions, and compensations. In building a basic process in BPMN, you can attach time-outs, exceptions, and compensations directly to a subprocess task list. When time-outs and exceptions occur within the process tasks, the process server traps these at the point of the subprocess.

Figure 2 presents a process server “architecture”, including a cloud services, for understanding the three types of errors. If the process server fails, then it obviously cannot run and a technical error occurs. If the ‘on-premise’ database service fails, then the process cannot get the data it needs to complete. This is a transient error. You should be able to restart the process instance and complete it once the database is restored. However cloud services are more complex, you might not have the same level of control that you would have for the database.

Users send data for the process in application servers. If users send incorrect data, then a business exception has occurred. Finally, you use process steps to resolve the error. If the users have used a cloud-bases SAS system to create a request or order, then more complexity is added.

Figure 2: Architecture for a process environment in a cloud-based ecosystem.

You can model business processes with advanced abilities that suspend processing, or communicate with disconnected, cloud-based processes. They can add new services and capabilities such as payments processing. These powers yield opportunities and fulfill the need for the enterprise to reduce the cost of their most complicated practices. Yet, to develop these cloud-based capabilities, you should understand how BPM tools use the three types of exceptions and what you must plan for when developing the production version of the process diagram.

Cloud-based- Error Handling Example

A process diagram should use exception handlers to redirect the process flow when a cloud based exception happens. So, if the subprocess in the figure below raises an error, then steps can be taken to accommodate the error.

Figure 3: using subprocess for exceptional flow

In BMPN, handling errors arising from a subprocess is known as ‘Exceptional flow’ and, for errors, this is always interrupting: the subprocess that generated the error will terminate, and the alternate “exceptional flow” is followed instead. Later, the process can merge exceptional flow with the main flow. The exceptional flow merge does not need to immediately return to the subprocess that generated the error. If required, a process model can merge several steps downstream.

Finally, cloud process integration diagrams in BPMN should include error handling, compensation, and transactions. All services have the potential for error conditions, understanding how to use BPMN to automate error handling and recover, or be survivable, is critical.

Bosch Software Innovations Webinar Series

2012-05-25T14:17:26Z

Bosch Software Innovations has made many changes over the past several years, plus our technology provides platforms for many new Bosch products and services. If you would like to hear more about Bosch’s ‘Connected World’, we are holding a BPM and BRM webinar series. At these webinars, you can learn from Bosch’s technical experts with in-depth industry knowledge, best practices and relevant solutions.

During the first webinar “Comprehensive Round-Trip BPM and BRM System at Best-in-Class TCO”, we will describe the Bosch approach and thinking about the benefits of using BRM and BPM. There will be a live product demonstration of inubit and Visual Rules. The webinar will cover these topics:

The integration of a inubit process and the Visual Rules engine
How our customers manage their projects on an enterprise level using
Our BPM and BRM methodology

In order to register, please visit Bosch’s website: here

On Bosch’s Connected World and the Internet of Things and Services

2012-05-19T02:26:37Z

On Tuesday, May 22, at 13:30(est) I gave an interview on the Peggy Smedley Show. Peggy’s show is the leading radio voice on the topic of the connected world and she has conducted interviews with many notable industry leaders.

The interview is available here.

By way of introduction, I want to describe Bosch’s relationship with the Connected World or what we call the Internet of Things and Services (IoTS).

Whatever label you choose to describe this, there are certainly many amazing new products and services arising from this architecture built on our pervasive wireless network - especially Verizon’s LTE. These IoTS ‘things’ include edge and hub products that are designed, built and offered by Bosch. The pervasive, sensor-driven, networked environment has arisen from the phenomena I call ‘Moore’s law everywhere’. This includes:

Ubiquitous, low cost (<$3) microprocessors and radios often found in innocuous products and devices, (some, such as light fixtures and ordinary appliances are unexpected)
Accelerating deployment of wireless bandwidth especially LTE
Big Data

Again, this environment is spawning new products and new business models, many led by Bosch business units in the areas of security technology, telemedicine, renewable energy, and consumer products. Some business sectors, such as manufacturing and security, are leveraging the situational awareness potential. Other business sectors, including telemedicine, are using the efficiency and asset savings characteristics.

Since 2008, when Bosch acquired Innovations Software, we have been methodically creating IoTS solutions through a framework called the Internet Application Platform (IAP). At the core of the IAP is the robust, industry leading BPM platform inubit and the Visual Rules BRMS. Bosch has great depth and experience in developing solutions for the IoTS and our IAP has already solved complex IoTS challenges. Now with these developments, we are moving into the era of what Forrester calls the Big Process and activities, information and decisions will be pushed to the “edge” - as close as possible to the customer and trading partner.

Yet, the IoTS is more than an interesting technological development or architecture. At the core, it is a set of solutions that are driven by global political, economic and social forces. A core value for Bosch is supporting the long-term viability of the communities we serve and we see the IoTS as a critical, global development for creating a more sustainable world. In many ways, IoTS solutions, via the Bosch Connected World, support the sustainability movement within business and government. The Bosch Connected World solutions span the important vertical domains of security, energy, environment, risk and finance. Briefly, here are the critical market drivers for these solutions:

Financial Strains: business and government investments in new infrastructure is limited and often there is inadequate maintenance and poor operations
Eroding Infrastructure: especially in the US there is an over-stressed electrical grid
Increasing security needs: in the US there is zero tolerance for acts of terror, this yields more complexity, more need for autonomous intelligent decisions, more situational awareness
Risk Management: there is an accelerated need to measure and control financial risk
Consumer Expectations: there is an emphasis on comfort, safety and security
Aging Demographics: this is not only true in the US but also Europe, increasing health care needs within declining budgets

The bottom-line: the mandate is not only ‘do more with less’ it is ‘do much more with even less’. Surprisingly, despite being internet-based, the autonomous local controls are critical.

The Bosch Connected World IoTS solutions support the sustainability objectives of business and government. Connected World solutions span these domains:

Security, physical and information
Energy Solutions, including new building energy systems, grid solutions and renewable energy
Environment, water and air
Risk Management
Finance Controls and Integration

Conclusion

We have learned many unexpected lessons in developing solutions for the IoTS and we are constantly adding new depth and experience. We will be providing details on this in the coming weeks.