Machine Learning Impact on IoT - Part 2

Editor's Notes

• #3: Designing with artificial intelligence The secret to getting people to engage with products and services is to make interaction as simple as possible. Remove friction and people will embrace your product. But simplicity isn’t the same as minimalism. The secret to getting people to engage with products and services is to make interaction as simple as possible. Remove friction and people will embrace your product. But simplicity isn’t the same as minimalism. For IoT devices, the interface may be as minimal as a few LEDs and a touchpad—and that kind of minimalism can feel obscure and confusing to users. What’s more, IoT devices often need to operate in concert to create delightful services, such as coordinating the levels of light and sound in a room. This simply increases complexity. Unless we come up with new ideas, the world is about to feel terribly broken. That’s why interfaces and services increasingly rely on artificial intelligence technologies. Algorithms make sense of contextual data, anticipate user needs, and accept more natural forms of input, like voice commands. Keeping the interface simple means the device has to become more intelligent. AI isn’t magic—it’s engineering. To develop compelling products, designers and product managers need to understand the constraints and possibilities of AI. They also need to develop new ways of working together so that the resulting products and services feel more… human. This session looks at how algorithms work, examines what they can and can’t do, and explores case studies and examples of how product teams have combined a deep understanding of people with clever design and smart algorithms to produce truly wonderful products. Decisions of what data to keep, ignore, and what to forward to a centralized authority will be required. Many of the kinetic devices will be used and application whose action can neither tolerate long latency nor risk the possibility that the connection with the centralized authority (“the cloud”) is not available. Their decisions must be made instantly with local information and knowledge. Most IoT endpoints will be limited in capabilities due to size, cost, and the power requirements and will need companion computing that is either embedded in the larger system or in a companion gateway. These gateways will primarily bridge between the local device communication domains and higher level network domains and will in most cases make behavioral decisions. As the industry matures, these gateways will also be responsible for allowing data to be exchanged between intended devices, and ensuring the information is protected. Network traffic patterns will be significantly impacted as more device-to-endpoint traffic will occur and more machine-to-machine communication will materialize, shifting from today’s patterns. However, these solutions will not be static, and their evolving behavior will need to vary depending on local characteristics, giving rise to more software-defined functions at both the edge and within the datacenter. Further, their numbers will be vast and their operation cannot require human intervention.
• #23: The input data consists of "train_FD001.txt", "test_FD001.txt", and "RUL_FD001.txt" in the original data source [1]. The training data ("train_FD001.txt") consists of multiple multivariate time series with "cycle" as the time unit, together with 21 sensor readings for each cycle. Each time series can be assumed as being generated from a different engine of the same type. Each engine is assumed to start with different degrees of initial wear and manufacturing variation, and this information is unknown to the user. In this simulated data, the engine is assumed to be operating normally at the start of each time series. It starts to degrade at some point during the series of the operating cycles. The degradation progresses and grows in magnitude. When a predefined threshold is reached, then the engine is considered unsafe for further operation. In other words, the last cycle in each time series can be considered as the failure point of the corresponding engine. Taking the sample training data shown in the following table as an example, the engine with id=1 fails at cycle 192, and engine with id=2 fails at cycle 287. The testing data ("test_FD001.txt") has the same data schema as the training data. The only difference is that the data does not indicate when the failure occurs (in other words, the last time period does NOT represent the failure point). Taking the sample testing data shown in the following table as an example, the engine with id=1 runs from cycle 1 through cycle 31. It is not shown how many more cycles this engine can last before it fails. The ground truth data ("RUL_FD001.txt") provides the number of remaining working cycles for the engines in the testing data. Taking the sample ground truth data shown in the following table as an example, the engine with id=1 in the testing data can run another 112 cycles before it fails.
• #27: Selected raw features The raw features are those that are included in the original input data. In order to decide which raw features should be included in the training data, both the detailed data field description and domain knowledge is helpful. In this template, all the sensor measurements (s1-s21) are included in the training data. Other raw features get used are: cycle, setting1-setting3. Aggregate features These features summarize the historical activity of each asset. In the template, two types of aggregate features are created for each of the 21 sensors. The description of these features are shown below. a1-a21: the moving average of sensor values in the most w recent cycles sd1-sd21: the standard deviation of sensor values in the most w recent cycles