A frame grabber is an electronic device that captures (i.e., "grabs") individual, digital still frames from an analog video signal or a digital video stream. It is usually employed as a component of a computer vision system, in which video frames are captured in digital form and then displayed, stored, transmitted, analyzed, or combinations of these. Historically, frame grabber expansion cards were the predominant way to interface cameras to PCs. Other interface methods have emerged since then, with frame grabbers (and in some cases, cameras with built-in frame grabbers) connecting to computers via interfaces such as USB, Ethernet and IEEE 1394 ("FireWire"). Early frame grabbers typically had only enough memory to store a single digitized video frame, whereas many modern frame grabbers can store multiple frames. Modern frame grabbers often are able to perform functions beyond capturing a single video input. For example, some devices capture audio in addition to video, and some devices provide, and concurrently capture frames from multiple video inputs. Other operations may be performed as well, such as deinterlacing, text or graphics overlay, image transformations (e.g., resizing, rotation, mirroring), and conversion to JPEG or other compressed image formats. To satisfy the technological demands of applications such as radar acquisition, manufacturing and remote guidance, some frame grabbers can capture images at high frame rates, high resolutions, or both. == Circuitry == Analog frame grabbers, which accept and process analog video signals, include these circuits: Input signal conditioner that buffers the analog video input signal to protect downstream circuitry Video decoder that converts SD analog video (e.g., NTSC, SECAM, PAL) or HD analog video (e.g., AHD, HD-TVI, HD-CVI) to a digital format Digital frame grabbers, which accept and process digital video streams, include these circuits: Digital video decoder that interfaces to and converts a specific type of digital video source, such as Camera Link, CoaXPress, DVI, GigE Vision, LVDS, or SDI Circuitry common to both analog and digital frame grabbers: Memory for storing the acquired image (i.e., a frame buffer) A bus interface through which a processor can control the acquisition and access the data General purpose I/O for triggering image acquisition or controlling external equipment == Applications == === Healthcare === Frame grabbers are used in medicine for many applications, including telenursing and remote guidance. In situations where an expert at another location needs to be consulted, frame grabbers capture the image or video from the appropriate medical equipment, so it can be sent digitally to the distant expert. === Manufacturing === "Pick and place" machines are often used to mount electronic components on circuit boards during the circuit board assembly process. Such machines use one or more cameras to monitor the robotics that places the components. Each camera is paired with a frame grabber that digitizes the analog video, thus converting the video to a form that can be processed by the machine software. === Network security === Frame grabbers may be used in security applications. For example, when a potential breach of security is detected, a frame grabber captures an image or a sequence of images, and then the images are transmitted across a digital network where they are recorded and viewed by security personnel. === Personal use === In recent years with the rise of personal video recorders like camcorders, mobile phones, etc. video and photo applications have gained ascending prominence. Frame grabbing is becoming very popular on these devices. === Astronomy & astrophotography === Amateur astronomers and astrophotographers use frame grabbers when using analog "low light" cameras for live image display and internet video broadcasting of celestial objects. Frame grabbers are essential to connect the analog cameras used in this application to the computers that store or process the images.
The Business Cloud
The Business Cloud is an API enabled self-service platform, developed by Domo, that provides an array of services like data connection and data visualization. == History == Domo, Inc. was founded in 2010 by Josh James who also co-founded the web analytics software company Omniture in 1996, which he took public in 2006. Domo launched the Domo Appstore, with 1,000 apps with social and mobile capabilities, in 2016. This appstore creates a network of business apps and an ecosystem of companies into a single, integrated business cloud. This decision came after Domo announced a $131 million round of funding from BlackRock. According to the company, the concept behind The Business Cloud is to connect smaller clouds relating to apps or other functional areas of a business into a single business cloud that allows self-service and other social features to customers. == Services == The Business Cloud is offered as a free service, claimed to be the world's first business cloud with Domo appstore as one of its core services. This free package includes all of the Domo's features and functionality including Domo platform, Domo Apps, visualizations, alerts, company directories, org charts, profiles, tasks and Domo Mobile. The Business Cloud allows customers to leverage their preferred cloud as well as on-premises software and monitor all aspects of their business in routine. The company is supported by a $500 million fund from investors all over the world.
Magiran
Magiran (Persian: مگیران)—Iran's publications database—is a digital library that was founded in 2000 and includes digitized versions of scientific journals, which currently provides the possibility of searching among the full text of 1,500 journals. Registration is required for full access to the database, but access to some items such as newspapers is also possible without registration. A list of Iranian researchers is also maintained there.
SCADA Strangelove
SCADA Strangelove is an independent group of information security researchers founded in 2012, focused on security assessment of industrial control systems (ICS) and SCADA. == Activities == Main fields of research include: Discovery of 0-day vulnerabilities in cyber physical systems and coordinated vulnerability disclosure; Security assessment of ICS protocols and development suites; Identification of publicly Internet-connected ICS components and secure it with help of proper authorities; Development of security hardening guides for ICS software; Mapping cybersecurity on to functional safety; Awareness control and delivery of information regarding the actual security state of ICS systems. SCADA Strangelove's interests expand further than classic ICS components and covers various embedded systems, however, and encompass smart home components, solar panels, wind turbines, SmartGrid as well as other areas. == Projects == Group members have and continue to develop and publish numerous open source tools for scanning, fingerprinting, security evaluation and password bruteforcing for ICS devices. These devices work over industrial protocols such as modbus, Siemens S7, MMS, ISO EC 60870, ProfiNet. In 2014 Shodan used some of the published tools for building a map of ICS devices which is publicly available on the Internet. Open source security assessment frameworks, such as THC Hydra, Metasploit, and DigitalBond Redpoint have used Shodan-developed tools and techniques. The group has published security-hardening guidelines for industrial solutions based on Siemens SIMATIC WinCC and WinCC Flexible. The guidelines contain detailed security configuration walk-throughs, descriptions of internal security features and appropriate best practices. Among the group’s more noticeable projects is Choo Choo PWN (CCP) also named the Critical Infrastructure Attack (CIA). This is an interactive laboratory built upon ICS software and hardware used in real world. Every system is connected to a toy city infrastructure, which includes factories, railroads and other facilities. The laboratory has been demonstrated at various conferences including PHDays, Power of Community, and 30C3. Primarily the laboratory is used for the discovery of new vulnerabilities and for evaluation of security mechanisms, however it is also used for workshops and other educational activities. At Positive Hack Days IV, contestants found several 0-day vulnerabilities in Indusoft Web Studio 7.1 by Schneider Electric, and in specific ICS hardware RTU PET-7000 during the ICS vulnerability discovery challenge. The group supports Secure Open SmartGrid (SCADASOS) project to find and fix vulnerabilities in intellectual power grid components such as photovoltaic power station, wind turbine, power inverter. More than 80 000 industrial devices were discovered and isolated from the Internet in 2015. == Appearances == Group members are frequently seen presenting at conferences like CCC, SCADA Security Scientific Symposium, Positive Hack Days. Most notable talks are: === 29C3 === An overview of vulnerabilities discovered in the widely distributed Siemens SIMATIC WinCC software and tools that are implemented for searching ICS on the Internet. === PHDays === This talk consisted of an overview of vulnerabilities discovered in various systems produced by ABB, Emerson, Honeywell and Siemens and was presented at PHDays III and PHDays IV. === Confidence 2014 === Implications of security research aimed at realization of various industrial network protocols Profinet, Modbus, DNP3, IEC 61850-8-1 (MMS), IEC (International Electrotechnical Commission) 61870-5-101/104, FTE (Fault Tolerant Ethernet), Siemens S7. === PacSec 2014 === Presentations of security research showing the impact of radio and 3G/4G networks on the security of mobile devices as well as on industrial equipment. === 31C3 === Analysis of security architecture and implementation of the most wide spread platforms for wind and solar energy generation which produce many gigawatts of it. === 32C3 === Cybersecurity assessment of railway signaling systems such as Automatic Train Control (ATC), Computer-based interlocking (CBI) and European Train Control System (ETCS). === China Internet Security Conference 2016 === In "Greater China Cyber Threat Landscape" keynote by Sergey Gordeychik an overview of vulnerabilities, attacks and cyber-security incidents in Greater China region was presented. === Recon 2017 === In talk "Hopeless: Relay Protection for Substation Automation" by Kirill Nesterov and Alexander Tlyapov security analysis results of key Digital Substation component - Relay Protection Terminals was presented. Vulnerabilities, including remote code execution in Siemens SIPROTEC, General Electric Line Distance Relay, NARI and ABB protective relays was presented. == Philosophy == All names, catchwords and graphical elements refer to Stanley Kubrick’s film, Dr. Strangelove. In their talks, group members often refer to Cold War events such as the Caribbean Crisis, and draw parallels between nuclear arms race and the current escalation of cyberwar. Group members follow the approach of “responsible disclosure” and “ready to wait for years, while vendor is patching the vulnerability”. Public exploits for discovered vulnerabilities are not published. This is on account of the longevity of ICS and by implication the long process of patching ICS. However, conflicts still happen, notably in 2012 when the talk at DEF CON was called off due to a dispute of persistent weaknesses in Siemens industrial software.
Resilience week
Resilience week is an annual symposium established to enable cross-disciplinary and role based discussions to advance strategies and research that engenders resilience in critical infrastructure systems and communities. Damaging storms, cyber attack and the interconnection of critical infrastructure systems can lead to cascading events that not only affect local but also across regions. However, many of these interdependencies are not easily recognized and obscure and complicate the mitigation of risk. The purpose of the symposia series is hence to facilitate best practice in managing critical infrastructure risks, by bringing together businesses, government and researchers. == Background == Originally organized in 2008 as a focus on the new research area of resilient control systems, including the disciplinary areas of control system, cyber-security, cognitive psychology and any number of critical infrastructure domains. Resilience has long been recognized as an area that requires not only the contributions of multiple disciplines or multidisciplinary participation, but interdisciplinary interaction where there is a common language and familiarity of the contributors to what other disciplines (and roles) contribute. The resulting interactions developed by Resilience Week and associated activities are intended to culture this sharing environment as a safe zone for inclusion; more importantly, an environment that lends to developing the new science and practice. As the attributes of resilience are complex, the contributions and topics for the event have included both the disciplinary and the project considerations, in keynotes, panels and research presentations. Keynotes have included senior leadership in the Department of Energy, Department of Defense, Department of Homeland Security, the National Science Foundation, and other agencies in addition to National Academy and professional organization fellows and senior industry leaders. Project panels and research presentations include emergent topics in resilience to climate change, cyber attack, damaging storms and the energy assurance. Topics Areas of focus have included: Control Systems Cyber Systems Cognitive Systems Communications Systems Communities and Infrastructure Project Focus Areas have included: Dependencies and Interdependencies Cyber Resilience for Operating Technology Commercializing Research and Development Building Critical Infrastructure Resilience through Distributed Energy Resources Energy Equity and Community Resilience Proceedings are developed for each year of the event, documenting the diversity of the research and engagements within these topical areas. == Impacts for the future == Since its inception, the Resilience Week community has evolved from one that primarily included only university researchers to one that includes many government laboratories, universities and private industries in the US and internationally. This type of collaboration forms a feedback loop that informs the research with the current needs and hones best practices. The future of the event is to further advance discussions that advance investment, recognize priorities and expedite technologies and tools to proactively address our energy future, in light of the natural and manmade challenges, and rationalizing the complex relationships that exist in critical infrastructure.
Systems development life cycle
The systems development life cycle (SDLC) describes the typical phases and progression between phases during the development of a computer-based system. These phases progress from inception to retirement. At base, there is just one life cycle, but the taxonomy used to describe it may vary; the cycle may be classified into different numbers of phases and various names may be used for those phases. The SDLC is analogous to the life cycle of a living organism from its birth to its death. In particular, the SDLC varies by system in much the same way that each living organism has a unique path through its life. The SDLC does not prescribe how engineers should go about their work to move the system through its life cycle. Prescriptive techniques are referred to using various terms such as methodology, model, framework, and formal process. Other terms are used for the same concept as SDLC, including software development life cycle (also SDLC), application development life cycle (ADLC), and system design life cycle (also SDLC). These other terms focus on a different scope of development and are associated with different prescriptive techniques, but are about the same essential life cycle. The term "life cycle" is often written without a space, as "lifecycle", with the former more popular in the past and in non-engineering contexts. The acronym SDLC was coined when the longer form was more popular and has remained associated with the expansion, even though the shorter form is popular in engineering. Also, SDLC is relatively unique as opposed to the TLA SDL, which is highly overloaded. == Phases == Depending on the source, the SDLC is described as having different phases and using different terms. Even so, there are common aspects. The following attempts to describe notable phases using notable terminology. The phases are somewhat ordered by the natural sequence of development, although they can be overlapping and iterative. === Conceptualization === During conceptualization (a.k.a. conceptual design, system investigation, feasibility), options and priorities are considered. A feasibility study can determine whether the development effort is worthwhile via activities such as understanding user needs, cost estimation, benefit analysis, and resource analysis. A study should address operational, financial, technical, human factors, and legal/political concerns. === Requirements analysis === Requirements analysis (a.k.a. preliminary design) involves understanding the problem and determining what is needed. Often this involves engaging users to define the requirements and recording them in a document known as a requirements specification. === Design === During the design phase (a.k.a. detail design), a solution is planned. The plan can include relatively high-level information such as describing the major components of the system. The plan can include relatively low-level information such as describing functions, screen layout, business rules, and process flow. The design phase is informed by the requirements of the system. The design must satisfy each requirement. The design may be recorded in textual documents as well as functional hierarchy diagrams, example screen images, business rules, process diagrams, pseudo-code, and data models. === Construction === During construction (a.k.a. implementation, production), the system is realized. Based on the design, hardware and software components are created and integrated. This phase includes testing sub-components, components and the integration of some components, but typically does not include testing at the complete system level. This phase may include the development of training materials, including user manuals and help files. === Acceptance === The acceptance phase (a.k.a. system testing) is about testing the complete system to ensure that it meets customer expectations (requirements). === Deployment === The deployment phase (a.k.a. implementation) involves the logistics of delivery to the customer. Some systems are deployed as a single instance (i.e. in the cloud), and deployment may be ad hoc and manual. Some systems are built in quantity and are associated with manufacturing process and commissioning. This phase may include training users to use the system. It may include transitioning future development to support staff. === Maintenance === During the maintenance phase (a.k.a. operation, utilization, support) development is largely inactive, although this phase does include customer support for resolving user issues and recording suggestions for improvement. Fixes and enhancements are handled by returning to the first phase, conceptualization. For minor changes, the cycle may be significantly abbreviated compared to initial development. === Decommission === Decommission (a.k.a. disposition, retirement, phase-out) is when the system is removed from use, i.e., when it reaches end-of-life. == Practices == === Management and control === SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives while executing projects. Control objectives are clear statements of the desired result or purpose and should be defined and monitored throughout a project. Control objectives can be grouped into major categories (domains), and relate to the SDLC phases as shown in the figure. To manage and control a substantial SDLC initiative, a work breakdown structure (WBS) captures and schedules the work. The WBS and all programmatic material should be kept in the "project description" section of the project notebook. The project manager chooses a WBS format that best describes the project. The diagram shows that coverage spans numerous phases of the SDLC, but the associated MCD (Management Control Domains) shows mappings to SDLC phases. For example, Analysis and Design is primarily performed as part of the Acquisition and Implementation Domain, and System Build and Prototype is primarily performed as part of delivery and support. === Work breakdown structured organization === The upper section of the WBS provides an overview of the project scope and timeline. It should also summarize the major phases and milestones. The middle section is based on the SDLC phases. WBS elements consist of milestones and tasks to be completed rather than activities to be undertaken, and have a deadline. Each task has a measurable output (e.g., an analysis document). A WBS task may rely on one or more activities (e.g., coding). Parts of the project needing support from contractors should have a statement of work (SOW). The development of an SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by contractors. === Baselines === Baselines are established after four of the five phases of the SDLC, and are critical to the iterative nature of the model. Baselines become milestones. functional baseline: established after the conceptual design phase. allocated baseline: established after the preliminary design phase. product baseline: established after the detailed design and development phase. updated product baseline: established after the production construction phase. In the following diagram, these stages are divided into ten steps, from definition to creation and modification of IT work products:
Data item
A data item describes an atomic state of a particular object concerning a specific property at a certain time point. A collection of data items for the same object at the same time forms an object instance (or table row). Any type of complex information can be broken down to elementary data items (atomic state). Data items are identified by object (o), property (p) and time (t), while the value (v) is a function of o, p and t: v = F(o,p,t). Values typically are represented by symbols like numbers, texts, images, sounds or videos. Values are not necessarily atomic. A value's complexity depends on the complexity of the property and time component. When looking at databases or XML files, the object is usually identified by an object name or other type of object identifier, which is part of the "data". Properties are defined as columns (table row), properties (object instance) or tags (XML). Often, time is not explicitly expressed and is an attribute applying to the complete data set. Other data collections provide time on the instance level (time series), column level, or even attribute/property level.