172,648 research outputs found
Model Style Guidelines for Embedded Code Generation
International audienceEmbedded systems are increasingly being developed using models. These models may have started with the system engineer or algorithm developer as an executable specification or algorithm description. However, these models also now serve as the entry point for software engineering, thanks to automatic embedded code generation. As a result, software engineers want to take advantage of these same models, adding constraints on system behavior; describing characteristics that are needed for implementation, such as fixed-point details; or linking components in the design to relevant parts of requirements and specification documents. This paper describes model style guidelines for automatically generating fixed-point and floating-point code for embedded systems. The guidelines are based on best practices and techniques derived from actual industry examples in aerospace and automotive companies worldwide
MLPerf Inference Benchmark
Machine-learning (ML) hardware and software system demand is burgeoning.
Driven by ML applications, the number of different ML inference systems has
exploded. Over 100 organizations are building ML inference chips, and the
systems that incorporate existing models span at least three orders of
magnitude in power consumption and five orders of magnitude in performance;
they range from embedded devices to data-center solutions. Fueling the hardware
are a dozen or more software frameworks and libraries. The myriad combinations
of ML hardware and ML software make assessing ML-system performance in an
architecture-neutral, representative, and reproducible manner challenging.
There is a clear need for industry-wide standard ML benchmarking and evaluation
criteria. MLPerf Inference answers that call. In this paper, we present our
benchmarking method for evaluating ML inference systems. Driven by more than 30
organizations as well as more than 200 ML engineers and practitioners, MLPerf
prescribes a set of rules and best practices to ensure comparability across
systems with wildly differing architectures. The first call for submissions
garnered more than 600 reproducible inference-performance measurements from 14
organizations, representing over 30 systems that showcase a wide range of
capabilities. The submissions attest to the benchmark's flexibility and
adaptability.Comment: ISCA 202
Dialectic tensions in the financial markets: a longitudinal study of pre- and post-crisis regulatory technology
This article presents the findings from a longitudinal research study on regulatory technology in the UK financial services industry. The financial crisis with serious corporate and mutual fund scandals raised the profile of
compliance as governmental bodies, institutional and private investors introduced a ātsunamiā of financial regulations. Adopting a multi-level analysis, this study examines how regulatory technology was used by financial firms to meet their compliance obligations, pre- and post-crisis. Empirical data collected over 12 years examine the deployment of
an investment management system in eight financial firms. Interviews with public regulatory bodies, financial
institutions and technology providers reveal a culture of compliance with increased transparency, surveillance and
accountability. Findings show that dialectic tensions arise as the pursuit of transparency, surveillance and
accountability in compliance mandates is simultaneously rationalized, facilitated and obscured by regulatory
technology. Responding to these challenges, regulatory bodies continue to impose revised compliance mandates on
financial firms to force them to adapt their financial technologies in an ever-changing multi-jurisdictional regulatory landscape
Knowing A Few Rules Doesnāt Mean You Can Play the Game : The Limits of āBest Practiceā in Enterprise Systems.
We examine the common claim that "best practices" are encompassed and represented in Enterprise Systems (ES). We suggest that an ES can at best only represent the ostensive and not the performative elements of work tasks. Thus, representation of best practice in an ES does not take practical action into account. This has two important implications. First, ostensive abstractions of best practice in an ES are a sparse and superficial representation of a "good" business process, at a specific moment in time. Second, the practical understanding required for performance is often ignored in the ostensive representation of best practice in the implementation of an ES. This constrains user and business adaptability. Inflexible coding of ostensive business tasks furthermore leads to rigidity where flexibility should be sought, to keep on top of the competition. Implications and directions for further research are discussed
Reengineering Biomedical Engineering Curricula: A New Product Development Approach
Product development engineers in medical industries have created design control procedures to ensure high quality designs that are as error-free as possible. The reason is simple; companies must adhere to certain engineering and manufacturing best practices in order to obtain certification of their devices for sale in the US and abroad. We describe here an ongoing effort to apply these industrial best practices to the design and implementation of a novel sequence of undergraduate biomedical computing courses within the Department of Bio-medical Engineering at Marquette University (Milwaukee, Wisconsin). We have tightly integrated our industrial advisory board into this design and development effort. The board has contributed to significantly to the orderly generation of curricular requirements, the development of course implementation designs and the evaluation of these designs per requirements
Developing a distributed electronic health-record store for India
The DIGHT project is addressing the problem of building a scalable and highly available information store for the Electronic Health Records (EHRs) of the over one billion citizens of India
Safety-Critical Systems and Agile Development: A Mapping Study
In the last decades, agile methods had a huge impact on how software is
developed. In many cases, this has led to significant benefits, such as quality
and speed of software deliveries to customers. However, safety-critical systems
have widely been dismissed from benefiting from agile methods. Products that
include safety critical aspects are therefore faced with a situation in which
the development of safety-critical parts can significantly limit the potential
speed-up through agile methods, for the full product, but also in the
non-safety critical parts. For such products, the ability to develop
safety-critical software in an agile way will generate a competitive advantage.
In order to enable future research in this important area, we present in this
paper a mapping of the current state of practice based on {a mixed method
approach}. Starting from a workshop with experts from six large Swedish product
development companies we develop a lens for our analysis. We then present a
systematic mapping study on safety-critical systems and agile development
through this lens in order to map potential benefits, challenges, and solution
candidates for guiding future research.Comment: Accepted at Euromicro Conf. on Software Engineering and Advanced
Applications 2018, Prague, Czech Republi
Reasons behind ERP package adoption: a diffusion of innovations perspective
Enterprise Resource Planning (ERP) packages have been widely adopted and it is becoming clear that
this is driven by multiple rationales that may be simultaneously at odds and complimentary. In this
paper, we aim to develop a greater understanding of these rationales by taking ERP packages to be
innovations and analysing their adoption with reference to the theory of diffusion of innovations. In
particular, we consider the attributes of ERP packages that may affect their adoption such as relative
advantage, compatibility, complexiblity, trialability and observability. We argue that usersā
perceptions of these attributes are not always accurate and these āmisconceptionsā can further explain
reasons for ERP adoption or rejection. Although our analysis aims to provide rich insights into the
adoption of ERP packages, the results of the study are arguably of further interest to the more general
study of packaged software and the more established literature on custom development
- ā¦