China
Africa
Explore chapters and articles related to this topic
Construction of self-updating and reusable space models via vision-based sensing
Published in Manuel Martínez, Raimar Scherer, eWork and eBusiness in Architecture, Engineering and Construction, 2020
Database server is an important module in VIOLAS, as its underlying structure enables the access to distributed COM (component object model) objects over a network. COM is a software architecture that standardizes the programming interfaces, implementation models, and the data structures. Based on this architecture, distributed COM objects (DCOM 2004) are developed that can be employed by other applications remotely in a network environment. This allows the software components to access data or implement a function remotely from multiple distributed computers. In this context, the software components of VIOLAS (image processing units, application server, and the user interface server) act as client applications that request service from the database server. Database server manages the communication between these programs and the VIOLAS database. The programs can also communicate with each other utilizing the database as a broker. Note that simple text messages between the applications server and the distributed components (for camera and IPU status-checking or new-resource-sharing) are carried out withTCP socket connection rather than DCOM.
Unified Modeling Language
Published in Praveen Kumar, Jay Alameda, Peter Bajcsy, Mike Folk, Momcilo Markus, Hydroinformatics: Data Integrative Approaches in Computation, Analysis, and Modeling, 2005
Benjamin L. Ruddell, Praveen Kumar
The Component Object Model (COM) framework is the foundation of Microsoft Windows™-based applications and database systems [3]. The COM is a protocol that defines the structure of objects and interaction between different software components. COM standard components are compiled in a binary format and are fully modular. This means that regardless of the language they were developed in, or what application they were developed for, COM components may be accessed and reused by other applications. COM separates interface from implementation, meaning that specific object classes implement interfaces. Client applications do not interact directly with objects. They interact with standard interfaces, which are implemented in a unique fashion by each object that supports the interface. This will be clarified by an illustration later in this section. Because the ESRI ArcObjects and incorporated geodatabase technologies are built on the COM standard, the UML Object Model Diagrams (OMDs) presented in this chapter illustrate COM-compatible class structure design. A few minor additions to the strict UML standards are made for COM class notation. First, CoClasses are represented by three-dimensional shaded boxes, while Standard Classes are represented by an unshaded three-dimensional box. The three-dimensional graphic symbolizes that these class types are able to be instantiated as real objects. The abstract class is shown as a two-dimensional shaded rectangle. In addition, a new relationship, the “instantiation,” symbolizes that one class has been created by another. The instantiation relationship is similar to the “realization” type in standard UML. Finally, the ArcObjects do not support multiple inheritance. In other words, each class may only inherit from one parent class.
.NET, ActiveX, and COM
Published in Rick Bitter, Taqi Mohiuddin, Matt Nawrocki, LabVIEW™ Advanced Programming Techniques, 2017
Rick Bitter, Taqi Mohiuddin, Matt Nawrocki
The first requirement for using an ActiveX control or a COM object is that it be registered in the system. When applications like Microsoft Word are installed on a computer, the installer registers all of the COM objects in the system registry. Each time the application is started, the information in the registry is verified. There is a slightly different mechanism when the COM object or ActiveX control is contained in a Dynamic Link Library (DLL). The specifics will not be mentioned here; the important concept is that the item is known in the system.
An analytical approach to real-time bus signal priority system for isolated intersections
Published in Journal of Intelligent Transportation Systems, 2022
Bilal Thonnam Thodi, Bhargava Rama Chilukuri, Lelitha Vanajakshi
The proposed signal priority actions are implemented in Vissim using its COM (Component Object Model) interface. Via COM interface, it is possible to assess all the functions and data in Vissim from an external application, say a scripting language. Figure 5 shows the overall implementation of the proposed signal priority action in Vissim, explained as follows: First, the test-site network is loaded in Vissim and initialized. Simulation is updated in a discrete-time step, and an end of the cycle criterion is checked at the end of each step. If the criterion is not satisfied, existing signal timings are resumed and the simulation continues. If the criterion is satisfied, network traffic and bus data are collected and fed into the arrival time prediction system and then into the priority decision system (with architecture as shown in Figure 3). New green splits from the priority decision systems are then sent back to the controller and the simulation continues. This process is repeated until the total simulation period ends.
Combined connected vehicles and variable speed limit strategies to reduce rear-end crash risk under fog conditions
Published in Journal of Intelligent Transportation Systems, 2020
Yina Wu, Mohamed Abdel-Aty, Ling Wang, Md Sharikur Rahman
The scenario considering all non-connected vehicles without any control technique is firstly simulated as the reference. Then, the scenarios with the VSL and CV control strategies were developed in the simulation. The VSL algorithm was fulfilled by the Component Object Model (COM) interface, which is used to program and regulate vehicle movements. Meanwhile, the CV behavior was regulated by the external driver behavior model in VISSIM, and it was based on Intelligent Driver Module (IDM) and was developed with a C++ program (Wang, Abdel-Aty, et al., 2017). The values of the parameters in the IDM model were determined based on previous studies (Kesting et al., 2010; Li et al., 2017b; Milanés & Shladover, 2014; Rahman & Abdel-Aty, 2017; Talebpour & Mahmassani, 2016). The parameters of CVs behavior model are presented in Table 1.
Evaluation of countermeasures for red light running by traffic simulator–based surrogate safety measures
Published in Traffic Injury Prevention, 2018
Changju Lee, Jaehyun (Jason) So, Jiaqi Ma
Using a SSAM-based traffic conflict technique requires vehicle trajectory data produced from VISSIM. Exploiting the advanced capability of VISSIM (i.e., Component Object Model interface) enables the acquisition of information for the surrogate safety measure of RLR. This information includes (1) signal information (e.g., signal state, signal head location [link/lane/linkcoord], yellow signal interval, signal controller/group/head numbers); (2) a vehicle's maneuvering information (e.g., vehicle ID, speed, acceleration, length, location [x, y, z coordinates]); and (3) vehicle information captured in the dilemma zone. SSAM captures all vehicle-to-vehicle interactions from vehicle trajectory data, thereby enabling the computation of surrogate safety measures for a pair of vehicles. These measures include minimum time-to-collision (TTC), minimum postencroachment time (PET), initial deceleration rate (DR), maximum deceleration rate (MaxD), and maximum speed (MaxS; FHWA 2008). Even though different measures have been recently used in traffic conflict analyses (e.g., Nadimi et al. 2016; Vasconcelos et al. 2013), TTC and PET continue to be regarded as critical indicators in safety assessment analyses (Killi and Vedagiri 2014; Shahdah et al. 2014; Tang and Nakamura 2009; R. Van Der Horst and Hogema 1993; Vogel 2003; Zhou and Huang 2013). Additionally, from the previous literature (e.g., Fitzsimmons et al. 2007; Hu et al. 2011), right-angle and rear-end crashes generally occur at intersections because of RLR, which can be elaborated by crossing and rear-end conflicts. Given that TTC and PET are the best measures for crossing and rear-end conflicts, respectively (Alhajyaseen 2014), these conflicts are identified using SSAM by the threshold values of TTC and PET.