dataesr/scientific-paragraphs-categorization huggingface dataset:
PoS(ICRC2023)1185 Hannah Wistrand successful detectors, and it can be used for various missions aimed at observing VHE neutrinos -including a follow-up balloon mission to EUSO-SPB2. Applications include identifying potential observing targets for Mini-EUSO  [20] , a JEM-EUSO instrument equipped with a fluorescence telescope installed on the International Space Station. Additional applications include other balloon missions such as PUEO  [21]  and satellite missions such as Terzina  [22]  and POEMMA  [4]. After the software is finalized and documented, it will be open source and available via GitHub.
Acknowledgements -The authors acknowledge the support by  NASA  awards  11-APRA-0058 ,  16-APROBES16-0023 ,  17-APRA17-0066 ,  NNX17AJ82G ,  NNX13AH54G ,  80NSSC18K0246 ,  80NSSC18K0473 , 80NSSC19K0626 ,  80NSSC18K0464 ,  80NSSC22K1488 ,  80NSSC19K0627  and  80NSSC22K0426 , the  French space agency CNES, National Science Centre in Poland  grant n. 2017/27/B/ST9/02162 , and by  ASI-INFN  agreement n. 2021-8-HH. 0and its amendments. This research used resources of the  US National Energy Research Scientific Computing Center (NERSC) , the  DOE Science User Facility  operated under Contract No. DE-AC02-05CH11231. We acknowledge the  NASA BPO and CSBF  staffs for their extensive support. We also acknowledge the invaluable contributions of the administrative and technical staffs at our home institutions.
We propose a model-based procedure for preventing security threats using formal models. We encode system models and threats as satisfiability modulo theory (SMT) formulas. This model allows us to ask security questions as satisfiability queries. We formulate threat prevention as an optimization problem over the same formulas. The outcome of our threat prevention procedure is a suggestion of model attribute repair that eliminates threats. We implement our approach using the state-of-the-art Z3 SMT solver and interface it with the threat analysis tool THREATGET. We demonstrate the value of our procedure in two case studies from automotive and smart home domains.
If the motion sensor detects a movement, the user is notified by phone. It is possible to override the behavior, e. g. , the heating can be turned on remotely in case of late arrival. The web server protected by the firewall allows for access and information exchange from and to the smart home. The IoT sub-system protected by the firewall defines a security boundary called the IoT Device Zone. Communication should be confidential and encrypted outside the IoT Device, which is represented by the two associated assets. Threats in this smart home system are characterized by logical relations between elements, connectors and their attributes. Consider two potential threats that are applicable to this example: Threat 1: The web server enables data logging functionality without encrypting the data, and Threat 2: The mobile phone device is connected to the web server, without the web server enabling data logging.
Assume that the web server has data logging enabled, but no data encryption, thus matching Threat 1. If we consider this threat in isolation, we can eithrt repair it by turning off the data logging, or by implementing the data encryption on the web server. The first repair results in matching Threat 2. Only the second repair results in the removal of all security threats. Given two data encryption algorithms with costs c 1 and c 2 , where c 1 > c 2 , implementing the latter is the cost-optimal option. We see that an optimal preventive solution must consider simultaneous repair of multiple threats. A threat model consists of two main components, a system model and a database of threat rules. A system model provides an architectural view of the system under investigation, representing relevant components, their properties, as well as relations and dependencies between them 1.
System Model A system model M consists of: a set E of elements: an element e ∈ E is a typed logical (software, database, etc. ) or physical (ECUs, sensors, actuators, etc. ) component. a set C of connectors: a connector c ∈ C is a direct interaction between two elements, a source s(c) ∈ E and a target element t(c) ∈ E. a set A of security assets: an asset a ∈ A describes logical or physical object (such as an element or a connector) of value. Each element and connector can hold multiple assets. Similarly, each asset can be associated to multiple elements and connectors. a set B of security boundaries: a boundary b ∈ B describes a separation between logically, physically, or legally separated system elements. a set A of attributes: an attribute a ∈ A is a property that can be associated to a system elements, connectors and/or assets.
Attribute Repair as Weighted MaxSMT We encode the attribute repair problem (see Section 3. 1) as a weighted MaxSMT problem, in which F represents a (hard) assertion, while F 1 ,. , F m correspond to soft assertions and every soft assertion F i has an associated cost cost i. Definition 4 (Weighted MaxSMT  [1] ). Given an SMT formula F, a set of SMT formulas F 1 ,. , F m and a set of real-valued costs cost 1 ,. , cost m , the weighted MaxSMT problem consists in finding a subset K ⊆ M of indices with M = {1,. , m} such that: (1) F ∧ k∈K F k is satisfiable, and (2) the total cost i∈N \K cost i is minimized. We now sketch the encoding of the minimal attribute repair problem into weighted MaxSMT. We assume that we have a MaxSMT solver object, with the following functionality: push() -push new context to solver stack, pop() -pop context from solver stack, add(φ) -add new hard assertion φ, add_sof t(φ, c)add new soft assertion φ with weight c, solve() -check if formula is satisfiable, max_solver() -check if formula is max-satisfiable, and model() -generate and return a model witnessing satisfaction of a formula.
Implementation and Case Studies We did a prototype implementation of the proposed methods in Java and integrated it to THREATGET. We used THREATGET's threat database from automotive and IoT domains originating from multiple sources, including securityrelated standards and previously discovered threats. The tool imports system models as JSON files and threat descriptions as THREATGET rules, translates both to FOL SMT formulas and uses Z3 as the MaxSMT solver. The MaxSMT solver's results are used to compute the repair suggestions. While THREATGET is a proprietary software (with a free academic license), our threat repair extension is distributed under the BSD-3 license. We assume the default attribute change cost 1 and allow the user to change it using a CSV file. We apply our tool to two case studies from two domains: the smart home IoT application introduced as our motivating example in Section 1, and the vehicular telematic gateway.
A third key fob case study can be found in Appendix C, in which we compare the vanilla MaxSMT approach to the heuristic procedure. In this section, we report on the experimental results obtained by applying our threat repair approach. The model has been analysed against 169 IoT-related threat descriptions given in the form of threat log formulas. We applied both the full MaxSMT optimization procedure and its heuristic variant. Both the model and the database of IoT threat formulas are publicly available. Table  1  summarizes the outcomes. To accurately report the number of repairable formulas we implement Algorithm 2 without line 31. The cost reflects the number of attributes (per item) changed in the model because we set the cost per attribute to 1 in our experiments. We can observe that the heuristic procedure was able to repair 27 out of 36 found threats in less than 50 seconds.
We illustrate the repair process on two threats from the database of IoT security threats. We first consider the threat with the title "Attacker can deny the malicious act and remove the attack foot prints leading to repudiation issues". This threat is formalized using the threat logic formula ∃e. type(e) = Firewall ∧ (v(e, Activity Logging) ̸ = Yes ∨ v(e, Activity Logging) = Missing). The SMT solver finds that the model satisfies the above formula and hence has a threat. The witness shows that one element of type 'Firewall' has the 'Activity Logging' attribute set to 'undefined', thus explaining the threat. The proposed repair consists in implementing the activity logging functionality. This repair was found to be consistent with the other ones and is reported as part of the overall repair suggestion.
A System Model This section defines a formal model that we use to analyze a system against a database of threats. A system model provides an architectural view of the system under investigation, representing relevant components, their properties, as well as relations and dependencies between them. Complete, formal definitions of the system and the threat model are given in  [3]. The system model is designed from a set of available entities, such as elements, connectors, security assets and security boundaries. These entities are typed, can have attributes (properties) assigned to values drawn from some domain. The entity types, attributes and domains are not arbitrary -they are selected from a predefined "arena" that we call a meta model. Before providing a formal definition of a meta model, we introduce useful notation.
We illustrate one of the proposed prevention measures. Manipulation of vehicular data: this threat is present because a malicious user could connect a Linux machine to the USB interface, access the CAN bus via the Infotainment system, manipulate command data and send them to the ECUs through the CAN bus. The recommended prevention measure consists in implementing authentication for connections to the USB interface, which would result in ignoring unauthenticated command messages. We summarize the evaluation of this case in Table  6. We first tried the vanilla procedure (Algorithm 1). The procedure gave an UNSAT verdict in 3. 65s, despite the fact that all unrepairable rules (according to the has_attr() syntactic check) were removed from the optimization. This result indicates that that there are a-priori repairable threat formulas that are either inconsistent with the system model or with another threat formula.
⋆ This project has received funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreements No  956123  ( FOCETA ), No  871385  (TEACHING) and from the program " ICT of the Future " of the  Austrian Research Promotion Agency (FFG)  and the  Austrian Ministry for Transport, Innovation and Technology  under grant agreements No. 867558  (project TRUSTED). This preprint has not undergone peer review (when applicable) or any post-submission improvements or corrections.
g. Julia, 2022;  Koch, Lorenzen, Pauli, & Allgower, 2020; MathWorks, 2022; Python, 2022; Rossiter, 2017)  and more. As part of the IFAC 50-year celebrations, a temporary control education resources website was created and subsequently a member of the Spanish community offered a website as the base for a more formal repository  (Control, 2022). However, neither of these was particularly effective in achieving high visibility to the community or gathering a wide range of resources. In recent years, the IFAC council also ran a pilot project on the potential for developing and maintaining a control repository, but sadly decided that the economic costs of doing this well were beyond their means and thus, at least for the time being, have paused any work on this. Hence, in the last 2-3 years  (Rossiter et al.
Indeed, this also allows easy extension to higher order systems and potentially more interesting examples which the lecturer can provide pre-packaged for the students to use. Such prepackaged scenarios can also include a variety of important and realistic issues such as uncertainty, faults and disturbances. One of the authors has a number of these coded on MATLAB (e. g. Koch et al. , 2020; Rossiter, 2017)  which students seem to appreciate and other authors have found Python and Julia popular  (Julia, 2022; Python, 2022) , the last two presenting the advantage of offering a free and open-source solution.
This is an integrative project that combines ideas from all the areas mentioned earlier. It showcases the full stack of modern data-driven design to students -from doing experiments and collecting the data, to learning a model based on it, to designing a decision-rule/control-law based on this model, implementing it, and observing how it behaves in the physical world. For all of this, they have built circuits, programmed a microcontroller and used Python to identify system dynamics (learn the model) and build a classifier. The course sequence is built around six modules as below: • (16A) Introduction to systems (tomography/medical imaging, matrices, inverse problems, PageRank) • (16A) Introduction to circuit design (touchscreen design, circuit components, basic feedback using op-amps) • (16A) Introduction to machine learning (GPS design, least squares, sparsity, Orthogonal Matching Pursuit) • (16B) Introduction to differential equations (Transistors, CMOS, RLC, time constants, filters) • (16B) Introduction to robotics and control (Stability, controllability, feedback) • (16B) Introduction to unsupervised machine learning and classification (singular value decomposition, principal components analysis, linearization, classification).
The idea behind modeling and how to use this idea is explicitly discussed. We try to get students to question assumptions, explicitly introduce proofs and talk about design and debugging. The course goes significantly deep and is not intended to be a survey class. Admittedly, the goals for the course here are a bit ambitious, and achieving them comes with some trade-offs. First, in order to be able to discuss applications in detail, we spread out the content of a one semester linear-algebra course over two semesters. We also rely on students having taken calculus in their high-school or community college. 1  We also require that students take a Python-based introductory CS course as a co-requisite to be adequately prepared. The course workload is quite high, with a total of eight minimum contact hours per week (three lecture + two discussion section + three lab) and additional time spent on homework.
Description and usage of the TCLab take home equipment The temperature control lab (TCLab) is a very cheap (circa 40 dollars) take-home micro-controller with two temperature sensors, two heaters, and an LED indicator (see Fig. 4 ). The device connects to a local computer via a USB and uses a simple domestic power source. Critically therefore, each student can borrow for the entire semester a TCLab device and thus use these safely at home to reinforce each concept in a dynamics and control course. An open source website (Temperature, 2023) provides 23 lab modules that reinforce major topics of a typical dynamics and control course with source code in Python (interactive Jupyter notebooks) and Matlab (interactive live scripts and Simulink). Instructors at 70 universities have adopted the TCLab as a take-home lab experience with several adaptations of the content based on experiential learning time (typically 1 week to 12 weeks).
Control systems course at Imperial College London: On-site and remote quadrotor test-bed experiment Continuing the theme of laboratory activities in engineering education, here, we discuss a hybrid implementation which mixes remote and face to face access. The section discusses the integration into the second-year basic Control Systems course at Imperial College London of a laboratory test-bed developed to replicate the dynamic behavior and the control design challenges of an under-actuated multi-rotor Unmanned Aerial Vehicle (UAV) (Fig. 9 ). The test-bed ANT-X 2DoF Drone (ANT, 2020) is based on a quadrotor UAV fixed to a structure that allows only the longitudinal motion. Using specific open-source firmware developed in Simulink, the drone can be directly operated from MATLAB, relieving students from coding implementation issues.
θ = 𝑞 𝐽 𝜃 q = 𝑀 𝑐 + 𝑀 𝑒 (1) There are two operational modes for the drone: (i) attitude mode (1 DoF) is achieved by constraining the linear displacement DoF through removable mechanical constraints (1DoF rings) and (ii) in position mode (2 DoFs) the drone is free to move along the bars with two DoFs (translation and rotation). The 2DoF Drone software architecture is based on PX4, an open source flight stack for drones, widely used in academia and industry, and on ROS, which provides a communication infrastructure. Moreover, there are two proprietary software tools. The first allows automatic integration of attitude and position controllers, designed in Simulink and customizable by the user, into the PX4 firmware. This tool does not require programming skills and allows the user to focus on the design of control laws, although the PX4 firmware can be modified directly, if needed, by advanced users.
The identification problem, especially for 𝜔 𝑛 and 𝜉, can use standard second order dynamics observations linked to frequency of oscillation and decay. Due to the derivative term in the numerator, a doublet signal input can be used to estimate gain 𝜇 by ensuring the model (3) response matches the equipment. Finally, the time delay 𝜏 can be estimated by visual inspection of the response or by using the Matlab delayest () routine on the collected data. An illustration of the time-domain verification of the identified model can be seen in Fig. 10.
INTRODUCTION In 1965, C. A. R. Hoare proposed in a series of papers on "record handling" an extension for a general purpose language, there supposed to be ALGOL 60, to manipulate an arbitrary number of records each belonging to a limited number of record classes  [Hoare 1965 [Hoare , 1966a,b],b]. Not only the proposal was rapidly adopted by ALGOL, but Dahl and Nygaard also adapted it for their language, Simula I, yielding the concepts of objects and classes (Simula 67). Ever since then, records have become the Swiss Army knife data structure of modern computer languages. They are used for a wide palette of purposes such as relations (as in relational databases), maps (a. k. a. , associative arrays, dictionaries, hashes, lookup tables), modules, objects, con guration les, data serialization.
JSON, the de facto standard format for data-interchange, is a language formed essentially of records and lists thereof. The same holds true for YAML, a di erent data serialization format used for con guration les. In general terms, record values are sets of key and value pairs in which all keys are pairwise distinct and are used to access the values they are paired with. In this work, we focus on two main distinct usages of records: structs and maps. In a nutshell, the former associate di erent keys to values of di erent types, they are accessed by providing nominal keys, and trying to access a non-existent key yields an error; the latter associate all keys to values of the same type, they are accessed by providing expressions that compute a key, and trying to access a non-existent key usually yields some default value such as null or nil.
-Accessing a key that is not de ned yields an error. -Structs are (often) immutable data-structures but may have mutable components. Besides these linguistic di erences, maps and structs may have di erent implementations, typically, hashes or search trees for maps; arrays or contiguous locations for structs. 1 When both are available, the choice to use one or the other depends on the nature of the application; in some cases, even for the same application both choices may reasonably apply, and the nal choice depends on the amount of information that is available about the data to process: for instance, to parse JSON we want to use structs if we know the eld name and data type of each JSON element, while for parsing unknown JSON data we should de nitively use maps. In some languages, the type used for keys is di erent between structs and maps (e.
g. , Go Language  [Go] , Erlang  [Erlang] , Swift  [Swift] ); in the last case there is a wealth of blog posts and tutorials about when to use one rather than the other. Many languages do not provide them as primitive data types, but rather as libraries or speci c classes, in which case they lack speci c types for them (e. g. ,  Ruby [Ruby]  and Scala  [Scala]  provide classes for both structs and maps, F# [F# ], JavaScript, Julia  [Julia ] , OCaml  [OCaml ] , and Rust  [Rust ]  have primitive objects/records/structs and libraries/classes for maps, while Python and Perl have primitive maps/dictionaries/hashes and records/structs are provided by external libraries/classes). While it is sensible to have di erent implementations for maps and structs, it is less justi ed to have di erent types for them, especially in languages in which the two data structures share the same or similar syntax for expressions and the same set of operations (as a matter of fact, both are nite functions from keys to values).
This is the case for some object-oriented languages in which maps have all the same interface typing di erent implementations (e. g. , in Java); a language like Ballerina permits to specify in a record type a default type for unspeci ed elds (thus mixing structs and maps characteristics) while Erlang's and Elixir's Typespecs permit mixing in the same record type the type speci cation of single elds (as in structs) and of mappings from key types to value types (as in maps)  [Elixir; Erlang]. The latter case is the inspiration of our work. In this article, we argue that a single (syntactic) representation for both struct and maps is possible, and that it can be typed by a unique type constructor that covers both cases. In this case, we will speak generically of "record expressions" (or just "records") as sets of associations between keys and values.
Of course, it will be possible to use both kinds of access on a same record: the di erent semantics will be re ected by di erent typing rules for the access expressions. Some languages already make this distinction for accesses: for instance in Elixir (but it is the same syntax as in JavaScript and in Ballerina) if r is a record expression, key is a nominal key, and keyexp an expression that computes a key, then r. key raises an exception if a eld with key key is not present in the result of r (i. e. , struct-like access), while r [keyexp] returns nil if the key resulting from keyexp is not present in (the result of) r (i. e. , map-like access). Likewise, Scala uses the syntax r (key) for struct-like access and r get keyexp for map-like access; however Scala also permits the use of generic expressions in the former-as in r (keyexp)-while Elixir has a speci c access function for this case-i.
e. , fetch!(r ,keyexp) (cf. Section 4. 5). Contributions. Per se, de ning a type system that encompasses both structs and maps does not look like an insurmountable task, and certainly it is not so hard to do it for languages with simple or no subtyping relation. The challenge here is that we aim at de ning types for dynamic languages such as JavaScript, Erlang, or Elixir. As all current attempts demonstrate (e. g. ,  Flow, TypeScript, Hack,. )  this requires types that include union and intersection type connectives, which imply the presence of a sophisticated subtyping relation. Thus, the real challenge we tackle here is to de ne a type system with union, intersection, and record (i. e. , struct+map) types. This means to show how to de ne and e ciently decide the subtyping relation for these types, and how to type record operations for expressions whose types may be arbitrary combinations of unions and intersections of record types.