Component-Based Sensor Software Toolset for Rapid Development
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Developing sensor-enabled software applications is challenging due to the asynchronous nature of sensor data, the variety of sensor types, and the complexity of data processing and interlinking, requiring significant programmer effort for data acquisition, processing, and storage.
Innovation Solution
A component-based software toolset is introduced, comprising class definitions for sensor-related components such as data source, data series, data destination, data field, and event components, allowing programmers to build complex applications by linking and configuring these components to facilitate rapid development of sensor data acquisition and processing flows.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If dedicated program code is added for each sensor type and connection, then sensor data collection capability is improved, but programming complexity and development time increase significantly
Solution Approach 1:
The patent divides the sensor data collection system into separate, reusable components: a base sensor class and multiple derived sensor classes (audio sensor, video sensor, image sensor, etc.). Each sensor type is implemented as an independent component that can be selectively instantiated and connected to data sources, allowing complex sensor networks to be built by composing simpler units rather than writing dedicated code for each sensor type.
Solution Approach 2:
The patent creates a universal sensor interface framework where a base sensor class provides common functionality for all sensor types. The base class includes methods for connecting to data sources, receiving data, and handling events, which are then inherited and extended by specific sensor implementations. This allows a single codebase to support multiple sensor types through inheritance rather than requiring separate dedicated code for each.
2Measurement precision
If asynchronous sensor data events are coordinated, then data processing accuracy is improved, but development effort and system complexity increase
Solution Approach 1:
The patent implements an event-driven architecture where sensor components automatically generate and emit events when data is available. The data processing system subscribes to these events and receives notifications asynchronously. This feedback mechanism ensures that data processing occurs at the appropriate moment without requiring complex manual coordination, as the system automatically responds to data availability through event subscriptions and callbacks.
Solution Approach 2:
The patent establishes data processing pipelines and event subscriptions in advance before data collection begins. Processing components are pre-configured with event handlers and data flow paths, so when asynchronous data events occur, the processing logic is already in place and ready to execute immediately. This preliminary setup eliminates the need for dynamic coordination during runtime.
3Adaptability or versatility
If sensor data is collected from multiple sources and processed, then application functionality is improved, but code quantity and maintenance complexity increase
Solution Approach 1:
The patent merges common sensor data collection and processing functionality into shared base classes and utility components. The base sensor class consolidates common operations such as data source connection, event emission, and data reception. Processing functions are merged into reusable data processing components that can handle multiple sensor types through polymorphism, reducing the need for duplicate code across different sensor implementations.
Solution Approach 2:
The patent uses template classes and generic programming constructs that can be instantiated with different sensor types without requiring separate implementation code. By using templates and inheritance, the same base code structure can be copied and adapted to work with different sensor types (audio, video, image, etc.) through parameterization rather than duplication.
4Productivity
If component-based architecture is used, then development speed is improved, but system integration complexity increases
Solution Approach 1:
The patent introduces an event bus or message queue as an intermediary layer between sensor components and data processing components. This intermediary handles the communication and data flow coordination automatically, allowing components to be added or modified independently without requiring direct integration code between all components. The event bus mediates asynchronous communication and data routing, simplifying the integration of new sensor types or processing logic.
Data Source
Figure 1~3
Figure 4~5
Figure 6
AI summary
The teachings herein disclose methods and apparatus that provide software components (objects) as building blocks for rapidly developing sensor-enabled software applications. In at least one embodiment, a component-based software toolset provides data source components (30) for obtaining sensor data, data series components (32) for automatically collecting sensor data incoming from data source components, data field components (42) for controlling that collection, and data destination components (34) for automatically receiving data from the data series components. By providing methods and properties within these and other components in the toolset, the programmer builds sophisticated, hierarchical data flow processing with little or no manual programming. The toolset may further include group components for merging data from multiple data series components, and for linking different data series components, and the data source/destination component definitions may include network socket-enabled components for LAN, WAN data collection, for example.