dataesr/scientific-paragraphs-categorization huggingface dataset:
us, we find many possibilities: Counter with CBC-MAC (CCM), Galois/Counter Mode (GCM), Electronic Codebook (ECB), etc. [37]. e most adapted cryptographic mechanisms for constrained devices are CCM and GCM  [38]. In addition, AES-CCM is widely used because it has better security properties compared to AES-GCM  [39, 40]. us, we propose AES-CCM to provide the communications of our CASPaaS with data integrity, authentication, and confidentiality. However, since AES is a symmetric encryption algorithm using the same secret key for both data encryption and decryption, both parties must have the same key. Key exchange over unsecure networks faces several security issues. Indeed, during the key exchange phase, it is possible that an adversary intercepts the key. Furthermore, in most systems, keys are stored on devices, and these devices can be captured or cloned.
Secure Data Exchange. After the initialization phase, the secure sending of the collected context information takes place. To do so, the context source CS i will need to create the shared secret key, noted Ssk, which will be used to encrypt the payload. First, this CS i creates a shared random secret value R, resulting from scalar multiplication taking as inputs the private key of CS i and the public key of the broker PkD. R � SkCS i × PkD. (4) en, the context source CS i provides the shared random secret value R as an input parameter of the key derivation function (KDF). e KDF determines the shared secret key Ssk and the message authentication code computation key K MAC. We propose to use a key derivation function based on HMAC-SHA-256. Indeed, the use of SHA-256 reduces the risk of success of brute-force attacks on the generated keys.
e context source CS i uses the shared secret key Ssk to encrypt the timestamped payload using 128-bit AES-CCM. e result of this operation is an encrypted message, denoted M ENC. From this M ENC and the K MAC key, CS i uses the HMAC-SHA256 function to compute a MAC tag. Finally, this CS i sends the couple (M ENC , tag) to the broker. Figure  5  illustrates the structure of the MQTT data packet formed by CS i. When the DTM receives the encrypted payload, it extracts the pair and does the reverse process using the CS i 's public key. To do so, it recomputes the shared secret key using the key derivation function and the parameters previously established with the context source. us, it computes a tag' and compares it to the tag sent by CS i. If tag' and tag are different, it aborts the process.
Overview. Context source trust management allows to manage trust relationships with context sources. It defines how to establish, maintain, or revoke a trust relationship with a device. e goal is to allow the context-awareness management system to handle only reliable context information provided by trusted context sources. is protects the CASPaaS architecture against erroneous or inappropriate adaptation decisions. ere are several models for managing trust relationships in IoT. Among these models, we can cite negotiation, reputation evaluation, and predefined policy decisions  [48]. e choice of a model is based, on the one hand, on the interaction model of different nodes and, on the other hand, on the data coming from these interactions. According to these elements, the reputation model approach is well suited for a context-aware security and privacy environment in the IoT.
Indeed, in this environment, we can have the data (reliability of context information and device behavior in our case) to evaluate experiences of context sources. Reputation can be considered trusting or not based on experiences and/or observations, whether good or bad. us, our trust Security and Communication Networks management system will be based on the reputation evaluation model. is reputation evaluation is based on the dynamic assessment of context information reliability and context source behavior. To do so, the context information reliability is evaluated using a Bayesian network. e context sources' behavior is evaluated according to the feedback from the MQTT broker (connection attempts, multiple authentication attempts, etc. ) and the DTM (e. g. , unauthenticated message). Figure  7  illustrates the proposed reputation assessment process.
Experiment Setup. In our simulation, we considered a user of a smart home application with three IoT devices as context sources: a connected smart watch, a connected pedometer (step counter), and a smartphone. ese devices are based on Raspberry Pi Zero W having a Broadcom     [56]. We have written the MQTT client in C++. us, we have used the CryptoPP library  [57]  to write the cryptographic algorithm to ensure the secure exchange of context information. e MQTT broker used is version 3. 1. 1 of Mosquitto, an open-source broker, also widely used  [58]  and written in C++/Python. We used the pyAgrum library to develop the Bayesian network for the detection of the reliability of context information  [59]. It is a powerful library written in C++ and adapted in Python. We also use the Python language to write fuzzy logic algorithms through the skfuzzy library  [60].
Custom-built microscopes often require control of multiple hardware devices and precise hardware coordination. It is also desirable to have a solution that is scalable to complex systems and that is translatable between components from different manufacturers. Here we report Python-Microscope, a free and open-source Python library for high-performance control of arbitrarily complex and scalable custom microscope systems. Python-Microscope offers simple to use Python-based tools, abstracting differences between physical devices by providing a defined interface for different device types. Concrete implementations are provided for a range of specific hardware, and a framework exists for further expansion. Python-Microscope supports the distribution of devices over multiple computers while maintaining synchronisation via highly precise hardware triggers.
INTRODUCTION The most advanced methods and applications in modern microscopy often require the assembly of custom-built specialised microscope systems. Such one-off systems may range from an off-the-shelf microscope stand with a range of specialised devices attached, to an advanced engineering project built from custom optical components. There are many unique examples in the literature of such systems. When building most such systems, software development to control a specific combination of hardware devices forms a large portion of the effort. Other than developing software from scratch, there are currently three popular routes for controlling custom microscopes: individual device vendor software unique to each manufacturer; microscope-specialised control software, with the most popular being Micro-Manager (μManager), a general Java-based framework with a graphical user interface (GUI) that has the lowest barrier to use; and custom control software, often written in LabVIEW or MATLAB, both of which are proprietary software.
LabVIEW offers a visual programming environment that is commonly used for building instruments in the physical sciences, whereas MATLAB is a programming environment with a focus on numeric computing. The solution requiring the least specialist knowledge is to use the device vendor software for the individual microscope components and run them in parallel. For example, one would open the light source, the camera and the stage programs separately, and place their individual windows side by side on the monitor to easily access all the controls. This solution is very convenient for simpler microscopes but lacks flexibility and scalability. Because the individual devices are being controlled using separate programs that do not communicate with each other, control of the microscope is effectively manual.
However, the widespread success of μManager means it has extensive hardware support and is often a good choice. LabVIEW (https://www. ni. com/en-us/shop/labview. html) is a visual programming language and development environment that is widely used in physical sciences for prototyping instruments. It has very wide hardware support, with many manufacturers providing LabVIEW modules (known as virtual instruments or VIs) to control their devices. Moreover, it allows very rapid development of GUIs with no previous programming knowledge. LabVIEW is proprietary and requires a commercial license for every computer it is used on, likely with associated cost. As each LabVIEW module is written by the equipment manufacturer, there is little consistency in how to interface different hardware. The visual nature of the programming environment makes simple projects easy, but systems with a large number of hardware components or complicated control architecture can become hard to understand, reproduce and maintain.
Although this complication can be reduced with good programming practices, it is not uncommon to outsource such work to a commercial company  (Chhetri et al. , 2020 preprint) , because good code writing in LabVIEW is significantly more challenging than in popular general-purpose languages such as Python. Additionally, the LabVIEW workflow does not integrate well into modern distributed source control infrastructure such as Mercurial or Git, a necessity for modern open-source development. MATLAB is a numerical-focused programming environment that scientists are often familiar with for data processing. It has frequently been used for microscopy, leveraging a number of available MATLAB subpackages to provide GUIs and easy access to complex data processing steps. The use of MATLAB for microscope control is common in the field, but the actual code is rarely shared and is often customised to a single microscope setup and associated with image reconstruction  (Chmyrov et al.
, 2013; Ta et al. , 2015). Exceptions are ScanImage for the control of laserscanning microscopes  (Pologruto et al. , 2003) , and MATLAB Instrument Control (MIC) for the control of individual microscope components  (Pallikkuth et al. , 2018). MATLAB provides a textual programming language, simplifying code sharing and version control; however, MATLAB is proprietary closed-source software, and the general requirement for many extensions significantly adds to the cost of implementing many systems. There are currently an increasing number of software options for microscope control written in Python, many of which are in the form of custom scripts specific to a microscope  (York et al. , 2013; Alvelid and Testa, 2019) , but some provide a fully integrated microscope control environment, namely PYME (https://www.
python-microscopy. org/) for single-molecule localisation microscopy (SMLM) and ACQ4  (Campagnola et al. , 2014)  for electrophysiology. Although this code is freely available and can be modified, its design around a specific setup, technique or environment reduces the potential for code reuse in other projects. Several microscope vendors, such as Abberior Instruments and Zeiss, provide Python interfaces to enable instrument control using Python. These are all very useful additions to proprietary systems; however, they have a fundamental drawback, in that each manufacturer produces their own abstractions, which means that code from one system is not compatible with another. Although these interfaces leverage the substantial Python infrastructure, they are not generalisable and hence fail to enhance portability or reproducibility.
The fact that these companies are providing Python interfaces to their instruments indicates the general interest of the community in Python as a programming language to extend hardware capabilities. This demonstrates the potential benefit of an entirely Python-based interface to a wide range of hardware. In order to provide an alternative route that mitigates against these limitations, we have developed Python-Microscope, a Python library that provides an abstracted high-level interface to control microscope devices. We have developed the software in Python, a programming language with which many researchers are already familiar, reducing the barriers to entry. Additionally, Python is a scripting language distributed as human-readable plain text files, is cross platform and does not require complex tool chains with compilation and linking steps, making it easier to share and reuse.
Library features The design of Python-Microscope was based around a series of use cases derived from the experience of microscope hardware and software developers: (1) code that is independent of specific device models and vendors; (2) creation of Python programs as microscope experiments; (3) distribution of devices over the network and horizontal scaling; (4) integration of high-performance hardware triggers and software triggers; (5) support of both software and hardware developers during the development phase. Here we describe these use cases and how Python-Microscope addresses them, with the details of implementation being described later.
Write once, run with any supported device A major design consideration is the ability to reuse code upon modification or reimplementation of a given microscope. This happens frequently: when replacing a specific device with a different model, either because the device failed or to get access features such as faster acquisition rates; when building a copy of the microscope on another site that has access to different devices; or as part of a larger improvement to an existing system, such as addition of a second light path with another camera. The ability to reuse the code after such changes to the system is critical, because it accelerates microscope development by eliminating or reducing the software development work, which is incidental to the main purpose of the microscope. At its core, Python-Microscope is a Python package that provides a defined interface for the different device types that may be used on a microscope.
This means that code written for a specific device type, such as a camera or light source, will work for all devices of that type. For example, to control the power output of a light source, manufacturer-supplied control software for different devices not only uses different commands and namessuch as power, intensity or flux but also different valuessuch as percentage, 0-1 range or intensity in milliwatts. In Python-Microscope, the interface for light sources specifies the 'power' attribute with a value in the 0-1 range for all light sources no matter what the underlying device implements. A simple example of Python-Microscope being used in this way is the BeamDelta program  (Hall et al. , 2019)  for alignment of optical systems, which uses Python-Microscope to interface to any supported camera.
Similarly, Microscope-AOtools  (Hall et al. , 2020)  implements different methods of adaptive optics and exploits Python-Microscope to handle the control and specifics of different cameras and deformable mirrors to provide virtual devices. Python-Microscope is also used to interface hardware in Microscope-Cockpit  (Phillips et al. , 2021)  (see Fig. S1 ) and PYME (https://www. python-microscopy. org/), programs that provide a GUI for complete microscopes and support a wide range of imaging modalities and a number of devices.
Python programs as microscope experiments The ability to write programs that are effectively microscopy experiments was an important goal. There are three reasons for this: first, to provide as much flexibility as possible, since GUIs are inherently limited by specific predesigned experiment types; second, to enable feedback of arbitrary image analysis into any step of the experiment control; and third, to simplify the sharing of even extremely complex experiments. The ability to write experiments as programs provides all these features. As Python-Microscope is a software library for controlling individual devices, it automatically supports the ability to create programs that are experiments. We have developed Python-Microscope so that such programs are easy to read and write, and even complex experiments can be encoded in easy-to-understand code (see examples in the documentation at https://github.
1 ). This happens even if all devices are connected to the same computer, since the client can connect to the server either locally or remotely. CryoSIM  (Phillips et al. , 2020)  and Aurox AO  (Hussain et al. , 2020)  are two example setups that use the Python-Microscope device-server program for hardware control in different ways. CryoSIM incorporates four lasers and two filter wheels on one computer, a spatial light modulator on a second computer, two cameras on a third computer and a fourth computer for overall system control, utilising the device-server program to distribute many devices over several computers. The Aurox AO setup has all the device servers on a single computer; however the device server model allows the integration of the Aurox Clarity module and a camera into a single composite device.
The Python-Microscope interface was designed with the concept of triggers that activate the individual devices, and software triggers are handled as simply another trigger type. This approach provides an interface that supports software triggers but is easily upgraded to support hardware triggers. The source of such hardware triggers can be other devicestypically a cameraor a dedicated triggering device. The recommended procedure is to prepare an experiment template that is then loaded on a dedicated timing device that triggers all other devices, as described in  Carlton et al. (2010). The existence of fast and cheap microprocessors and single board computers mean that providing a dedicated hardware timing to sequence and synchronise a number of devices is relatively easy and extremely cost effective.
Development tool Finally, Python-Microscope is a useful tool during the system development phase. There are two sides of system development: the development of the actual optical setup and the development of the software to control that optical setup. To support development of optical systems, Python-Microscope includes a simple GUI program for the different device types (Fig. 2 ). These are intentionally kept simple as their aim is to test the basic functionality of the device without the added complexity that a full microscope control GUI brings. To support development of user-facing software, Python-Microscope provides simulated devices that enable software development without physical access to the hardware. For example, the simulated camera device can be configured to return images with specific features, such as 2D Gaussian spots (Fig.
2A ), which were used during development of BeamDelta  (Hall et al. , 2019). Interaction between devices enables simulation of complex behaviour. For example, Python-Microscope provides a set of test devices to model sample navigation: a simulated camera uses the position of a simulated stage to 'acquire' an image that is a subsection of a larger image. Focal position is simulated by blurring the image based on the position of the z axis of the simulated stage and a 'channel' is selected based on the position of the simulated filter wheel. With hardware and software development happening concurrently, it is practical for one person to build the optical system and connect hardware while another is building the software. In doing so, total build time and costs can be reduced. Implementation Documentation for the software and usage examples are available online at https://python-microscope.
Abstract base classes Python-Microscope interfaces for the different device types are implemented as abstract base classes (ABCs) using Python's abc standard library. These device ABCs are incomplete implementations with concrete methods, which handle input validation and provide software fallbacks, and abstract methods for the individual device operations. Currently, ABCs have been implemented for cameras, light sources, filter wheels, stages and deformable mirrors, as well as integrated controllers that can control multiple pieces of hardware. All these ABCs inherit from a Device ABC, which defines core operations, such as device settings and shutdown. The interface to support hardware triggers is implemented via an ABC mixin, named TriggerTargetMixin, which is mixed with the individual device type ABCs.
Concrete implementations The implementation of a concrete class (i. e. support for a specific physical device) is device dependent, but typically it either wraps a vendor-provided C library or a direct communication link to the hardware. In the case of a C library, these are dynamically loaded with Python's ctypes standard library which removes the need for a compilation step or dependence on other tools. Direct communication is typically performed via RS-232 serial connections using Python's pySerial package (https://github. com/ pyserial/pyserial), frequently over USB to serial bridges in connected hardware. Concrete implementations have been created for multiple devices. The full list is expanding with each new release and is part of the Python-Microscope documentation available online (https://python-microscope.
Device server The device-server program creates a Pyro4 daemon (https://pyro4. readthedocs. io/) for each device. The Python-Microscope device instance is created and then registered with its Pyro4 daemon. There is only one Python-Microscope device instance per physical device. The Python multiprocessing standard library is used to place each Pyro4 daemon in its own Python process, effectively sidestepping Python's global interpreter lock (GIL). The device server can be configured to serve a set of devices on the same process in order to simplify inter-device communication, typically for composite virtual devices. Other instances that provide control of the hardware, such as individual stage axis and devices behind a controller, are registered with the Pyro4 daemon at initialisation. With Pyro4's autoproxy feature, these other instances are automatically replaced by a Pyro4 proxy on the client side.
GUI The microscope-gui program makes use of the QtPy package (https:// pypi. org/project/QtPy/), which abstracts the difference between PyQt5, PyQt4, PySide2 and PySide, which are all different Python wrappers to Qt (https://www. qt. io/), thus making the dependency a choice of the user. The dependency on QtPy itself is optional, making Python-Microscope easier to install if the GUI is not required. For each device ABC there is a corresponding QWidget class. This widget is the central and only widget of the microscope-gui program window. The widget classes are public, so they can be incorporated in other programs. It should be noted that microscope-gui is not intended as a generalised user interface to control microscopes, we expect it to be used for low-level hardware control under other software like Microscope-Cockpit (Fig.
Device-specific features An inherent limitation of defining an interface for different device types is the use of specialised device features that are specific to single device model or range of models. For example, some cameras have the option of applying denoising filters during acquisition, or provide control over amplifiers in the different stages of the camera readout. These features are exposed via a general 'settings' mode, which is effectively a map of feature names to values. Python-Microscope provides such settings even when they clash with properties that are part of Python-Microscope's interface. For example, Python-Microscope's camera interface has a binning property but instances of PVCamera might also have the BINNING_SER and BINNING_PAR settings. Direct use of such settings, instead of the defined interface, ties the resulting code to the specific device, reducing potential for reuse; hence, we recommend against such practice if possible.